Jonathan Lalou's Blog

Posts Tagged ‘JVM’

In the world of modern application deployment, particularly in cloud-native and microservice architectures, fast startup time is a crucial factor impacting scalability, resilience, and cost efficiency. Slow-starting applications can delay deployments, hinder auto-scaling responsiveness, and consume resources unnecessarily. Olivier Bourgain, in his presentation, delved into strategies for significantly accelerating the startup time of Java applications, focusing on optimizations at both the Java Virtual Machine (JVM) level and within popular frameworks like Spring Boot. He explored techniques ranging from garbage collection tuning to leveraging emerging technologies like OpenJDK’s Project Leyden and Spring AOT (Ahead-of-Time Compilation) to make Java applications lighter, faster, and more efficient from the moment they start.

The Importance of Fast Startup

Olivier began by explaining why fast startup time matters in modern environments. In microservices architectures, applications are frequently started and stopped as part of scaling events, deployments, or rolling updates. A slow startup adds to the time it takes to scale up to handle increased load, potentially leading to performance degradation or service unavailability. In serverless or function-as-a-service environments, cold starts (the time it takes for an idle instance to become ready) are directly impacted by application startup time, affecting latency and user experience. Faster startup also improves developer productivity by reducing the waiting time during local development and testing cycles. Olivier emphasized that optimizing startup time is no longer just a minor optimization but a fundamental requirement for efficient cloud-native deployments.

JVM and Garbage Collection Optimizations

Optimizing the JVM configuration and understanding garbage collection behavior are foundational steps in improving Java application startup. Olivier discussed how different garbage collectors (like G1, Parallel, or ZGC) can impact startup time and memory usage. Tuning JVM arguments related to heap size, garbage collection pauses, and just-in-time (JIT) compilation tiers can influence how quickly the application becomes responsive. While JIT compilation is crucial for long-term performance, it can introduce startup overhead as the JVM analyzes and optimizes code during initial execution. Techniques like Class Data Sharing (CDS) were mentioned as a way to reduce startup time by sharing pre-processed class metadata between multiple JVM instances. Olivier provided practical tips and configurations for optimizing JVM settings specifically for faster startup, balancing it with overall application performance.

Framework Optimizations: Spring Boot and Beyond

Popular frameworks like Spring Boot, while providing immense productivity benefits, can sometimes contribute to longer startup times due to their extensive features and reliance on reflection and classpath scanning during initialization. Olivier explored strategies within the Spring ecosystem and other frameworks to mitigate this. He highlighted Spring AOT (Ahead-of-Time Compilation) as a transformative technology that analyzes the application at build time and generates optimized code and configuration, reducing the work the JVM needs to do at runtime. This can significantly decrease startup time and memory footprint, making Spring Boot applications more suitable for resource-constrained environments and serverless deployments. Project Leyden in OpenJDK, aiming to enable static images and further AOT compilation for Java, was also discussed as a future direction for improving startup performance at the language level. Olivier demonstrated how applying these framework-specific optimizations and leveraging AOT compilation can have a dramatic impact on the startup speed of Java applications, making them competitive with applications written in languages traditionally known for faster startup.

Links:

• Olivier Bourgain: https://www.linkedin.com/in/olivier-bourgain/
• Mirakl: https://www.mirakl.com/
• Spring Boot: https://spring.io/projects/spring-boot
• OpenJDK Project Leyden: https://openjdk.org/projects/leyden/
• Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
• Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
• Devoxx France Website: https://www.devoxx.fr/

Jean-Philippe BEMPEL , a seasoned developer at Datadog and a Java Champion, delivered an insightful presentation on selecting and tuning Garbage Collectors (GCs) in OpenJDK to enhance Java application performance. His talk, rooted in practical expertise, unraveled the complexities of GCs, offering a roadmap for developers to align their choices with specific application needs. By dissecting the characteristics of various GCs and their suitability for different workloads, Jean-Philippe provided actionable strategies to optimize memory management, reduce production issues, and boost efficiency.

Understanding Garbage Collectors in OpenJDK

Garbage Collectors are pivotal in Java’s memory management, silently handling memory allocation and reclamation. However, as Jean-Philippe emphasized, a misconfigured GC can lead to significant performance bottlenecks in production environments. OpenJDK offers a suite of GCs—Serial GC, Parallel GC, G1, Shenandoah, and ZGC—each designed with distinct characteristics to cater to diverse application requirements. The challenge lies in selecting the one that best matches the workload, whether it prioritizes throughput or low latency.

Jean-Philippe began by outlining the foundational concepts of GCs, particularly the generational model. Most GCs in OpenJDK are generational, dividing memory into the Young Generation (for short-lived objects) and the Old Generation (for longer-lived objects). The Young Generation is further segmented into the Eden space, where new objects are allocated, and Survivor spaces, which hold objects that survive initial collections before promotion to the Old Generation. Additionally, the Metaspace stores class metadata, a critical but often overlooked component of memory management.

Serial GC: Simplicity for Constrained Environments

The Serial GC, one of the oldest collectors, operates with a single thread and employs a stop-the-world approach, pausing all application threads during collection. Jean-Philippe highlighted its suitability for small-scale applications, particularly those running in containers with less than 2 GB of RAM, where it serves as the default GC. Its simplicity makes it ideal for environments with limited resources, but its stop-the-world nature can introduce noticeable pauses, making it less suitable for latency-sensitive applications.

To illustrate, Jean-Philippe explained the mechanics of the Young Generation’s Survivor spaces. These spaces, S0 and S1, alternate roles as source and destination during minor GC cycles, copying live objects to manage memory efficiently. Objects surviving multiple cycles are promoted to the Old Generation, reducing the overhead of frequent collections. This generational approach leverages the hypothesis that most objects die young, minimizing the cost of memory reclamation.

Parallel GC: Maximizing Throughput

For applications prioritizing throughput, such as batch processing jobs, the Parallel GC offers significant advantages. Unlike the Serial GC, it leverages multiple threads to reclaim memory, making it efficient for systems with ample CPU cores. Jean-Philippe noted that it was the default GC until JDK 8 and remains a strong choice for throughput-oriented workloads like Spark jobs, Kafka consumers, or ETL processes.

The Parallel GC, also stop-the-world, excels in scenarios where total execution time matters more than individual pause durations. Jean-Philippe shared a benchmark using a JFR (Java Flight Recorder) file parsing application, where Parallel GC outperformed others, achieving a throughput of 97% (time spent in application versus GC). By tuning the Young Generation size to reduce frequent minor GCs, developers can further minimize object copying, enhancing overall performance.

G1 GC: Balancing Throughput and Latency

The G1 (Garbage-First) GC, default since JDK 9 for heaps larger than 2 GB, strikes a balance between throughput and latency. Jean-Philippe described its region-based memory management, dividing the heap into smaller regions (Eden, Survivor, Old, and Humongous for large objects). This structure allows G1 to focus on regions with the most garbage, optimizing memory reclamation with minimal copying.

In his benchmark, G1 showed a throughput of 85%, with average pause times of 76 milliseconds, aligning with its target of 200 milliseconds. However, Jean-Philippe pointed out challenges with Humongous objects, which can increase GC frequency if not managed properly. By adjusting region sizes (up to 32 MB), developers can mitigate these issues, improving throughput for applications like batch jobs while maintaining reasonable pause times.

Shenandoah and ZGC: Prioritizing Low Latency

For latency-sensitive applications, such as HTTP servers or microservices, Shenandoah and ZGC are the go-to choices. These concurrent GCs minimize pause times, often below a millisecond, by performing most operations alongside the running application. Jean-Philippe highlighted Shenandoah’s non-generational approach (though a generational version is in development) and ZGC’s generational support since JDK 21, making the latter particularly efficient for large heaps.

In a latency-focused benchmark using a Spring PetClinic application, Jean-Philippe demonstrated that Shenandoah and ZGC maintained request latencies below 200 milliseconds, significantly outperforming Parallel GC’s 450 milliseconds at the 99th percentile. ZGC’s use of colored pointers and load/store barriers ensures rapid memory reclamation, allowing regions to be freed early in the GC cycle, a key advantage over Shenandoah.

Tuning Strategies for Optimal Performance

Tuning GCs is as critical as selecting the right one. For Parallel GC, Jean-Philippe recommended sizing the Young Generation to reduce the frequency of minor GCs, ideally exceeding 50% of the heap to minimize object copying. For G1, adjusting region sizes can address Humongous object issues, while setting a maximum pause time target (e.g., 50 milliseconds) can shift its behavior toward latency sensitivity, though it may not compete with Shenandoah or ZGC in extreme cases.

For concurrent GCs like Shenandoah and ZGC, ensuring sufficient heap size and CPU cores prevents allocation stalls, where threads wait for memory to be freed. Jean-Philippe emphasized that Shenandoah requires careful heap sizing to avoid full GCs, while ZGC’s rapid region reclamation reduces such risks, making it more forgiving for high-allocation-rate applications.

Selecting the Right GC for Your Workload

Jean-Philippe concluded by categorizing workloads into two types: throughput-oriented (SPOT) and latency-sensitive. For SPOT workloads, such as batch jobs or ETL processes, Parallel GC or G1 are optimal, with Parallel GC offering easier tuning for predictable performance. For latency-sensitive applications, like microservices or databases (e.g., Cassandra), ZGC’s generational efficiency and Shenandoah’s low-pause capabilities shine, with ZGC being particularly effective for large heaps.

By analyzing workload characteristics and leveraging tools like GC Easy for log analysis, developers can make informed GC choices. Jean-Philippe’s benchmarks underscored the importance of tailoring GC configurations to specific use cases, ensuring both performance and stability in production environments.

Links:

• Datadog company website

• Jean-Philippe Bempel on Twitter/X

Hashtags: #Java #GarbageCollector #OpenJDK #Performance #Tuning #Datadog #JeanPhilippeBempel #OracleDevDays2025

Alina Yurenko 🇺🇦 , a developer advocate at Oracle Labs, captivated audiences at Devoxx France 2024 with her deep dive into GraalVM’s ahead-of-time (AOT) compilation for Java applications. With a passion for open-source and community engagement, Alina explored how GraalVM’s Native Image transforms Java applications into compact, high-performance native executables, ideal for cloud environments. Through demos and practical guidance, she addressed building, testing, and optimizing GraalVM applications, debunking myths and showcasing its potential. This post unpacks Alina’s insights, offering a roadmap for adopting GraalVM in production.

GraalVM and Native Image Fundamentals

Alina introduced GraalVM as both a high-performance JDK and a platform for AOT compilation via Native Image. Unlike traditional JVMs, GraalVM allows developers to run Java applications conventionally or compile them into standalone native executables that don’t require a JVM at runtime. This dual capability, built on over a decade of research at Oracle Labs, offers Java’s developer productivity alongside native performance benefits like faster startup and lower resource usage. Native Image, GA since 2019, analyzes an application’s bytecode at build time, identifying reachable code and dependencies to produce a compact executable, eliminating unused code and pre-populating the heap for instant startup.

The closed-world assumption underpins this process: all application behavior must be known at build time, unlike the JVM’s dynamic runtime optimizations. This enables aggressive optimizations but requires careful handling of dynamic features like reflection. Alina demonstrated this with a Spring Boot application, which started in 1.3 seconds on GraalVM’s JVM but just 47 milliseconds as a native executable, highlighting its suitability for serverless and microservices where startup speed is critical.

Benefits Beyond Startup Speed

While fast startup is a hallmark of Native Image, Alina emphasized its broader advantages, especially for long-running applications. By shifting compilation, class loading, and optimization to build time, Native Image reduces runtime CPU and memory usage, offering predictable performance without the JVM’s warm-up phase. A Spring Pet Clinic benchmark showed Native Image matching or slightly surpassing the JVM’s C2 compiler in peak throughput, a testament to two years of optimization efforts. For memory-constrained environments, Native Image excels, delivering up to 2–3x higher throughput per memory unit at heap sizes of 512MB to 1GB, as seen in throughput density charts.

Security is another benefit. By excluding unused code, Native Image reduces the attack surface, and dynamic features like reflection require explicit allow-lists, enhancing control. Alina also noted compatibility with modern Java frameworks like Spring Boot, Micronaut, and Quarkus, which integrate Native Image support, and a community-maintained list of compatible libraries on the GraalVM website, ensuring broad ecosystem support.

Building and Testing GraalVM Applications

Alina provided a practical guide for building and testing GraalVM applications. Using a Spring Boot demo, she showcased the Native Maven plugin, which streamlines compilation. The build process, while resource-intensive for large applications, typically stays within 2GB of memory for smaller apps, making it viable on CI/CD systems like GitHub Actions. She recommended developing and testing on the JVM, compiling to Native Image only when adding dependencies or in CI/CD pipelines, to balance efficiency and validation.

Dynamic features like reflection pose challenges, but Alina outlined solutions: predictable reflection works out-of-the-box, while complex cases may require JSON configuration files, often provided by frameworks or libraries like H2. A centralized GitHub repository hosts configs for popular libraries, and a tracing agent can generate configs automatically by running the app on the JVM. Testing support is robust, with JUnit and framework-specific tools like Micronaut’s test resources enabling integration tests in Native mode, often leveraging Testcontainers.

Optimizing and Future Directions

To achieve peak performance, Alina recommended profile-guided optimizations (PGO), where an instrumented executable collects runtime profiles to inform a final build, combining AOT’s predictability with JVM-like insights. A built-in ML model predicts profiles for simpler scenarios, offering 6–8% performance gains. Other optimizations include using the G1 garbage collector, enabling machine-specific flags, or building static images for minimal container sizes with distroless images.

Looking ahead, Alina highlighted two ambitious GraalVM projects: Layered Native Images, which pre-compile base images (e.g., JDK or Spring) to reduce build times and resource usage, and GraalOS, a platform for deploying native images without containers, eliminating container overhead. Demos of a LangChain for Java app and a GitHub crawler using Java 22 features showcased GraalVM’s versatility, running seamlessly as native executables. Alina’s session underscored GraalVM’s transformative potential, urging developers to explore its capabilities for modern Java applications.

Links:

• GraalVM website

• Oracle Labs website

• Devoxx France website

Hashtags: #GraalVM #NativeImage #Java #AOT #AlinaYurenko #DevoxxFR2024

At Devoxx France 2019, Olivier Revial, a developer at Stackeo in Toulouse, presented Micronaut: The Ultra-Light JVM Framework of the Future. This session introduced Micronaut, a modern JVM framework designed for microservices and serverless applications, offering sub-second startup times and a 10MB memory footprint. Through slides and demos, Revial showcased Micronaut’s cloud-native approach and its potential to redefine JVM development.

Limitations of Existing Frameworks

Revial began by contrasting Micronaut with established frameworks like Spring Boot and Grails. While Spring Boot simplifies development with auto-configuration and standalone applications, it suffers from runtime dependency injection and reflection, leading to slow startup times (20–25 seconds) and high memory usage. As codebases grow, these issues worsen, complicating testing and deployment, especially in serverless environments where rapid startup is critical. Frameworks like Spring create a barrier between unit and integration tests, as long-running servers are often relegated to separate CI processes.

Micronaut addresses these pain points by eliminating reflection and using Ahead-of-Time (AOT) compilation, performing dependency injection and configuration at build time. This reduces startup times and memory usage, making it ideal for containerized and serverless deployments.

Micronaut’s Innovative Approach

Micronaut, created by Grails’ founder Graeme Rocher and Spring contributors, builds on the strengths of existing frameworks—dependency injectiaon, auto-configuration, service discovery, and HTTP client/server simplicity—while introducing innovations. It supports Java, Kotlin, and Groovy, using annotation processors and AST transformations for AOT compilation. This eliminates runtime overhead, enabling sub-second startups and minimal memory footprints.

Micronaut is cloud-native, with built-in support for MongoDB, Kafka, JDBC, and providers like Kubernetes and AWS. It embraces reactive programming via Reactor, supports GraalVM for native compilation, and simplifies testing by allowing integration tests to run alongside unit tests. Security features, including JWT and basic authentication, and metrics for Prometheus, enhance its enterprise readiness. Despite its youth (version 1.0 released in 2018), Micronaut’s ecosystem is rapidly growing.

Demonstration

Revial’s demo showcased Micronaut’s capabilities. He used the Micronaut CLI to create a “hello world” application in Kotlin, adding a controller with REST endpoints, one returning a reactive Flowable. The application started in 1–2 seconds locally (6 seconds in the demo due to environment differences) and handled HTTP requests efficiently. A second demo featured a Twitter crawler storing tweets in MongoDB using a reactive driver. It demonstrated dependency injection, validation, scheduled tasks, and security (basic authentication with role-based access). A GraalVM-compiled version started in 20 milliseconds, with a 70MB Docker image compared to 160MB for a JVM-based image, highlighting Micronaut’s efficiency for serverless use cases.

Links:

• Micronaut Official Website
• Stackeo Official Website
• Olivier Revial’s GitHub

Hashtags: #Micronaut #Microservices #DevoxxFR2019 #OlivierRevial #JVMFramework #CloudNative

Lecturer

Roman Elizarov is a distinguished software developer with over 16 years of experience, currently serving as a senior engineer at JetBrains, where he has been a key contributor to Kotlin’s development. Previously, Roman worked at Devexperts, designing high-performance trading software and market data delivery systems capable of processing millions of events per second. His expertise in Java, JVM, and real-time data processing has shaped Kotlin’s coroutine framework, making him a leading authority on asynchronous programming. Roman’s contributions to Kotlin’s open-source ecosystem and his focus on performance optimizations underscore his impact on modern software development.

• JetBrains company website
• Roman Elizarov on LinkedIn

Abstract

Kotlin’s introduction of coroutines as a first-class language feature addresses the challenges of asynchronous programming in modern applications. This article analyzes Roman Elizarov’s presentation at KotlinConf 2017, which provides a comprehensive introduction to Kotlin coroutines, distinguishing them from thread-based concurrency and other coroutine implementations like C#’s async/await. It explores the context of asynchronous programming, the methodology behind coroutines, their practical applications, and their implications for scalable software development. The analysis highlights how coroutines simplify asynchronous code, enhance scalability, and integrate with existing Java libraries, offering a robust solution for handling concurrent tasks.

Context of Asynchronous Programming

The rise of asynchronous programming reflects the demands of modern applications, from real-time mobile interfaces to server-side systems handling thousands of users. Roman Elizarov, speaking at KotlinConf 2017 in San Francisco, addressed this shift, noting the limitations of traditional thread-based concurrency in monolithic applications. Threads, while effective for certain tasks, introduce complexity and resource overhead, particularly in high-concurrency scenarios like microservices or real-time data processing. Kotlin, designed by JetBrains for JVM interoperability, offers a pragmatic alternative through coroutines, a first-class language feature distinct from other implementations like Quasar or JavaFlow.

Roman contextualized coroutines within Kotlin’s ecosystem, emphasizing their role in simplifying asynchronous programming. Unlike callback-based approaches, which lead to “callback hell,” or reactive streams, which require complex chaining, coroutines enable synchronous-like code that is both readable and scalable. The presentation’s focus on live examples demonstrated Kotlin’s ability to handle concurrent actions—such as user connections, animations, or server requests—while maintaining performance and developer productivity, setting the stage for a deeper exploration of their mechanics.

Methodology of Kotlin Coroutines

Roman’s presentation detailed the mechanics of Kotlin coroutines, focusing on their core components: suspending functions and coroutine builders. Suspending functions allow developers to write asynchronous code that appears synchronous, pausing execution without blocking threads. This is achieved through Kotlin’s compiler, which transforms suspending functions into state machines, preserving execution state without the overhead of thread context switching. Roman demonstrated launching coroutines using builders like launch and async, which initiate concurrent tasks and allow waiting for their completion, streamlining complex workflows.

A key aspect of the methodology is wrapping existing Java asynchronous libraries into suspending functions. Roman showcased how developers can encapsulate callback-based APIs, such as those for network requests or database queries, into coroutines, transforming convoluted code into clear, sequential logic. The open-source Kotlinx Coroutines library, actively developed on GitHub, provides these tools, with experimental status indicating ongoing refinement. Roman emphasized backward compatibility, ensuring that even experimental features remain production-ready, encouraging developers to adopt coroutines with confidence.

Applications and Scalability

The practical applications of coroutines, as demonstrated by Roman, span mobile, server-side, and real-time systems. In mobile applications, coroutines simplify UI updates and background tasks, ensuring responsive interfaces without blocking the main thread. On the server side, coroutines enable handling thousands of concurrent connections, critical for microservices and high-throughput systems like trading platforms. Roman’s live examples illustrated how coroutines manage multiple tasks—such as animations or user sessions—efficiently, leveraging lightweight state management to scale beyond traditional threading models.

The scalability of coroutines stems from their thread-agnostic design. Unlike threads, which consume significant resources, coroutines operate within a single thread, resuming execution as needed. Roman explained that garbage collection handles coroutine state naturally, maintaining references to suspended computations without additional overhead. This approach makes coroutines ideal for high-concurrency scenarios, where traditional threads would lead to performance bottlenecks. The ability to integrate with Java libraries further enhances their applicability, allowing developers to modernize legacy systems without extensive refactoring.

Implications for Software Development

Kotlin coroutines represent a paradigm shift in asynchronous programming, offering a balance of simplicity and power. By eliminating callback complexity, they enhance code readability, reducing maintenance costs and improving developer productivity. Roman’s emphasis on production-readiness and backward compatibility reassures enterprises adopting Kotlin for critical systems. The experimental status of coroutines, coupled with JetBrains’ commitment to incorporating community feedback, fosters a collaborative development model, ensuring that coroutines evolve to meet real-world needs.

The implications extend beyond individual projects to the broader software ecosystem. Coroutines enable developers to build scalable, responsive applications, from mobile apps to high-performance servers, without sacrificing code clarity. Their integration with Java libraries bridges the gap between legacy and modern systems, making Kotlin a versatile choice for diverse use cases. Roman’s invitation for community contributions via GitHub underscores the potential for coroutines to shape the future of asynchronous programming, influencing both Kotlin’s development and the JVM ecosystem at large.

Conclusion

Roman Elizarov’s introduction to Kotlin coroutines at KotlinConf 2017 provided a compelling vision for asynchronous programming. By combining suspending functions, coroutine builders, and seamless Java interoperability, coroutines address the challenges of modern concurrency with elegance and efficiency. The methodology’s focus on simplicity and scalability empowers developers to create robust, high-performance applications. As Kotlin continues to evolve, coroutines remain a cornerstone of its innovation, offering a transformative approach to handling concurrent tasks and reinforcing Kotlin’s position as a leading programming language.

Links

• Introduction to Coroutines Video
• JetBrains company website
• Roman Elizarov on LinkedIn
• Kotlinx Coroutines GitHub

Tim Fox, the visionary project lead for Vert.x at Red Hat, charts the course of this lightweight, high-performance application platform for the JVM. With a storied tenure at JBoss and VMware—where he spearheaded HornetQ messaging and RabbitMQ integrations—Tim unveils Vert.x 2.0’s maturation into an independent powerhouse. His session delves into the revamped module system, Maven/Bintray reusability, and enhanced build tool/IDE synergy, alongside previews of Scala, Clojure support, and Node.js compatibility.

Vert.x 2.0 empowers polyglot, reactive applications, blending asynchronous eventing with synchronous legacy APIs via worker verticles. Tim’s live demos illustrate deploying modules dynamically, underscoring Vert.x’s ecosystem for mobile, web, and enterprise scalability.

Core API Refinements and Asynchronous Foundations

Tim highlights Vert.x’s event-driven core, refined in 2.0 with intuitive APIs for non-JVM languages. He demonstrates verticles—lightweight actors—for handling requests asynchronously, avoiding blocking calls.

This reactive model, Tim explains, scales to thousands of connections, ideal for real-time web apps, contrasting traditional thread-per-request pitfalls.

Module System and Ecosystem Expansion

The new module system, Tim showcases, leverages Maven repositories for seamless dependency management. He deploys a web server via module names, pulling artifacts from Bintray—eliminating manual installations.

This reusability fosters a vibrant ecosystem, with core modules for HTTP, MySQL (via reversed-engineered async drivers), and more, enabling rapid composition.

Build Tool and IDE Integration

Vert.x 2.0’s Maven/Gradle plugins streamline development, as Tim demos: configure a pom.xml, run mvn vertx:run, and launch a cluster. IDE support, via plugins, offers hot-reloading and debugging.

These integrations, Tim notes, lower barriers, allowing developers to iterate swiftly without Vert.x-specific tooling.

Polyglot Horizons: Scala, Clojure, and Node.js

Tim previews Scala/Clojure bindings, enabling functional paradigms on Vert.x’s event bus. Node.js compatibility, via drop-in modules, bridges JavaScript ecosystems, allowing polyglot teams to collaborate seamlessly.

This inclusivity, Tim asserts, broadens Vert.x’s appeal, supporting diverse languages without sacrificing performance.

Worker Verticles for Legacy Compatibility

For synchronous APIs like JDBC, Tim introduces worker verticles—executing on thread pools to prevent blocking. He contrasts with pure async MySQL drivers, offering flexibility for hybrid applications.

This pragmatic bridge, Tim emphasizes, integrates existing Java libraries effortlessly.

Links:

• Tim Fox on LinkedIn
• Red Hat company website

Lecturer

Charles Nutter has spent over a decade as a Java developer and more than six years leading the JRuby project at Red Hat. Co-lead of JRuby, he works to fuse Ruby’s elegance with the JVM’s power while contributing to other JVM languages and educating the community on advanced virtual machine capabilities. A proponent of open standards, he aims to keep the JVM the premier managed runtime through innovations like invokedynamic.

Abstract

Charles Nutter demystifies invokedynamic, the JVM bytecode instruction introduced in Java 7 to optimize dynamic language implementation. He explains its mechanics—bootstrap methods, call sites, and method handles—through progressive examples, culminating in a toy language interpreter. The presentation contrasts invokedynamic with traditional invokevirtual and invokeinterface, benchmarks performance, and illustrates how it enables JRuby and other languages to approach native Java speeds, paving the way for polyglot JVM ecosystems.

The Problem with Traditional Invocation: Static Assumptions in a Dynamic World

Nutter begins with the JVM’s historical bias toward statically-typed languages. The four classic invocation instructions—invokevirtual, invokeinterface, invokestatic, and invokespecial—assume method resolution at class loading or compile time. For dynamic languages like Ruby, Python, or JavaScript, method existence and signatures are determined at runtime, forcing expensive runtime checks or megamorphic call sites.

JRuby, prior to invokedynamic, relied on reflection or generated bytecodes per call, incurring significant overhead. Even interface-based dispatch suffered from inline cache pollution when multiple implementations competed.

Invokedynamic Mechanics: Bootstrap, Call Sites, and Method Handles

Introduced via JSR-292, invokedynamic defers method linking to a user-defined bootstrap method (BSM). The JVM invokes the BSM once per call site, passing a CallSite object, method name, and type. The BSM returns a MethodHandle—a typed, direct reference to a method—installed into the call site.

Nutter demonstrates a simple BSM:

public static CallSite bootstrap(MethodHandles.Lookup lookup, String name, MethodType type) {
    MethodHandle mh = lookup.findStatic(MyClass.class, "target", type);
    return new ConstantCallSite(mh);
}

The resulting invokedynamic instruction executes the linked handle directly, bypassing vtable lookups.

Call Site Types and Guarded Invocations

Call sites come in three flavors: ConstantCallSite for immutable linkages, MutableCallSite for dynamic retargeting, and VolatileCallSite for atomic updates. Guarded invocations combine a test (guard) with a target handle:

MethodHandle guard = lookup.findStatic(Guards.class, "isString", MethodType.methodType(boolean.class, Object.class));
MethodHandle target = lookup.findStatic(Handlers.class, "handleString", type);
MethodHandle fallback = lookup.findStatic(Handlers.class, "handleOther", type);
MethodHandle guarded = MethodHandles.guardWithTest(guard, target, fallback);

The JVM inlines the guard, falling back only on failure, enabling polymorphic inline caches.

Building a Toy Language: From Parser to Execution

Nutter constructs a minimal scripting language with arithmetic and print statements. The parser generates invokedynamic instructions with a shared BSM. The BSM resolves operators (+, -, *) to overloaded Java methods based on argument types, caching results per call site.

Execution flows through method handles, achieving near-Java performance. He extends the example to support runtime method missing, emulating Ruby’s method_missing.

Performance Analysis: Benchmarking Invocation Strategies

Nutter presents JMH benchmarks comparing invocation types. invokestatic serves as baseline; invokevirtual adds vtable dispatch; invokeinterface incurs interface check. invokedynamic with ConstantCallSite matches invokestatic, while MutableCallSite aligns with invokevirtual.

Key insight: the JVM’s optimizer treats stable invokedynamic sites as monomorphic, inlining aggressively. JRuby leverages this for core methods, reducing dispatch overhead by 10-100x.

Implications for JVM Languages and Future Evolution

Invokedynamic enables true polyglot JVMs. Nashorn (JavaScript), Dynalink, and Truffle frameworks build upon it. Future enhancements include value types and specialized generics, further reducing boxing.

Nutter concludes that invokedynamic fulfills John Rose’s vision: dynamic dispatch no slower than static, ensuring the JVM’s longevity as a universal runtime.

Links:

• Video of the lecture

Guillaume Laforge, the Groovy Project Lead and a key figure in its development since its inception, provided an extensive overview of Groovy’s advancements. Guillaume, employed by the SpringSource division of VMware at the time, highlighted how Groovy enhances developer efficiency and runtime speed with each iteration. He began by recapping essential elements from Groovy 1.8 before delving into the innovations of version 2.0, emphasizing its role as a versatile language on the JVM.

Guillaume underscored Groovy’s appeal as a scripting alternative to Java, offering dynamic capabilities while allowing modular usage for those not requiring full dynamism. He illustrated this with examples of seamless integration, such as embedding Groovy scripts in Java applications for flexible configurations. This approach reduces boilerplate and fosters rapid prototyping without sacrificing compatibility.

Transitioning to performance, Guillaume discussed optimizations in method invocation and arithmetic operations, which contribute to faster execution. He also touched on library enhancements, like improved date handling and JSON support, which streamline common tasks in enterprise environments.

A significant portion focused on modularity in Groovy 2.0, where the core is split into smaller jars, enabling selective inclusion of features like XML processing or SQL support. This granularity aids in lightweight deployments, particularly in constrained settings.

Static Type Checking for Reliability

Guillaume elaborated on static type checking, a flagship feature allowing early error detection without runtime overhead. He demonstrated annotating classes with @TypeChecked to enforce type safety, catching mismatches in assignments or method calls at compile time. This is particularly beneficial for large codebases, where dynamic typing might introduce subtle bugs.

He addressed extensions for domain-specific languages, ensuring type inference works even in complex scenarios like builder patterns. Guillaume showed how this integrates with IDEs for better code completion and refactoring support.

Static Compilation for Performance

Another cornerstone, static compilation via @CompileStatic, generates bytecode akin to Java’s, bypassing dynamic dispatch for speed gains. Guillaume benchmarked scenarios where this yields up to tenfold improvements, ideal for performance-critical sections.

He clarified that dynamic features remain available selectively, allowing hybrid approaches. This flexibility positions Groovy as a bridge between scripting ease and compiled efficiency.

InvokeDynamic Integration and Future Directions

Guillaume explored JDK7’s invokedynamic support, optimizing dynamic calls for better throughput. He presented metrics showing substantial gains in invocation-heavy code, aligning Groovy closer to Java’s performance.

Looking ahead, he previewed Groovy 2.1 enhancements, including refined type checking for DSLs and complete invokedynamic coverage. For Groovy 3.0, a revamped meta-object protocol and Java 8 lambda compatibility were on the horizon, with Groovy 4.0 adopting ANTLR4 for parsing.

In Q&A, Guillaume addressed migration paths and community contributions, reinforcing Groovy’s evolution as responsive to user needs.

His session portrayed Groovy as maturing into a robust, adaptable toolset for modern JVM development, balancing dynamism with rigor.

Links:

• Guillaume Laforge on LinkedIn

Case

Your project includes both Java classes and Groovy scripts. You would like to build all of them at the same time with Maven: this must be possible, because, after all, Groovy scripts are run on a Java Virtual Machine.

Solution

In your pom.xml, configure the maven-compiler-plugin as follows:
[xml] <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.0</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<source>1.6</source>
<target>1.6</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.8.0-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.1.5-03</version>
</dependency>
</dependencies>
</plugin>[/xml]
With such setup, default compiler (which cannot compile Groovy scripts parallelly of Java sources) will be replaced with Eclipse’s one (which can).

Lecturer

Alexis Moussine-Pouchkine, a veteran of Sun Microsystems, currently serves as a Developer Relations lead at Google in Paris, assisting developers in achieving success. With over a decade at Sun and nearly two years at Oracle, he brings extensive experience in Java ecosystems and cloud technologies.

Abstract

Alexis Moussine-Pouchkine’s presentation examines Java’s evolution and its potential trajectory in cloud computing. Reflecting on historical shifts in technology, he critiques current limitations and advocates for advancements like multi-tenancy and resource management to ensure Java’s relevance. Through industry examples and forward-looking analysis, the talk underscores the need for adaptation to maintain Java’s position amid resource rationalization and emerging paradigms.

Java’s Maturation and the Cloud Imperative

Moussine-Pouchkine opens by recounting his transition from Sun Microsystems to Oracle and then Google, highlighting how each company has shaped computing history. At Sun, innovation abounded but market fit was inconsistent; Oracle emphasized acquisitions over novelty, straining community ties; Google prioritizes engineers, fostering rapid development.

He likens Java’s current state to emerging from adolescence, facing challenges in cloud environments where resource optimization is paramount. Drawing from his engineering school days with strict quotas on compilation and connection time, Alexis contrasts this with Java’s initial promise of freedom and flexibility. Early experiences with Linux provided boundless experimentation, mirroring Java’s liberating potential in 1997.

The speaker invokes historical predictions: IBM’s CEO allegedly foresaw a market for only five computers in 1943, possibly prescient regarding cloud providers. Bill Gates’ 640K memory quip and Greg Papadopoulos’ 2003 vision of five to seven massive global computers underscore consolidation trends. Papadopoulos envisioned entities like Google, eBay, Salesforce, Microsoft, Amazon, and a Chinese cloud, a perspective less radical today given web evolution.

Java’s centrality in tomorrow’s cloud is questioned. While present in many offerings, most implementations remain prototypes, circumventing Java’s constraints. The cloud demands shared resources and concentration of expertise, yet Java’s future here is uncertain, risking obsolescence like COBOL.

Challenges and Necessary Evolutions for Java in Multi-Tenant Environments

A core issue is Java’s adaptation to multi-tenancy, where multiple applications share a JVM without interference. Current JVMs lack robust isolation, leading to inefficiencies in cloud settings. Moussine-Pouchkine notes Java’s success in Android and Chrome, where processes are segregated, but enterprise demands shared instances for cost savings.

He critiques the stalled JSR-284 for resource management, essential for quotas and usage-based billing. Without these, Java lags in cloud viability. Examples like Google’s App Engine illustrate Java’s limitations: no threads, file system restrictions, and 30-second request limits, forcing workarounds.

Commercial solutions emerge: Waratek’s hypervisor on HotSpot, IBM’s J9 VM, and SAP’s container enable multi-tenancy. Yet, quotas remain crucial for responsible computing, akin to not overindulging at a buffet to ensure sustainability.

Java 9 priorities include modularity (Jigsaw), potentially aiding resource management. Cloud Foundry’s varying memory allocations by language highlight Java’s inefficiencies. Moussine-Pouchkine urges a “slider” for JVM scaling, from minimal to robust, without API fractures.

The community, pioneers in agile practices, continuous integration, and dependency management, must embrace modularity and quotas. Java 7 introduced dynamic languages; Java 8 tackles multicore with lambdas. Recent Oracle slides affirm multi-tenancy and resource management in Java 9 and beyond.

Implications for Sustainable and Credible Informatics

Moussine-Pouchkine advocates responsible informatics: quotas foster predictability, countering perceptions of IT as imprecise and costly. Developers, like artisans, must steward tools and design thoughtfully. Over-reliance on libraries (90% bloat) signals accumulated technical debt.

Quotas enhance credibility, enabling commitments and superior delivery. Java’s adaptive history positions it well, provided the community envisions it “caffeinated” – vibrant and adult – rather than “decaffeinated” and stagnant.

In essence, Java must address multi-tenancy and resources to thrive in consolidated clouds, avoiding the fate of outdated technologies.

Relevant Links and Hashtags

Links:

• Video of the lecture
• Alexis Moussine-Pouchkine on LinkedIn