This discussion usually hinges on attempts to protect and advocate participants’ personal favourite approaches. But perhaps we’re missing the forest for the trees by focusing on these labels.

The Complexity Axis of Testing

Consider a complexity axis for your tests. On one end, we have clear-cut unit tests — simple, isolated, and unmistakable. Easy to run from the IDE without losing focus, repeatable, and you can easily come up with an example that would fit right in:

assertEquals(3, add(2, 1)); 

It’s as easy to bring an example or recognize some of the integration tests. You can probably tell an integration test by its use of multiple service components, like a database or a Kafka cluster, or having to deploy your app as a Kubernetes operator into an actual cluster, and so on. But it’s really not that easy to define what separates the two, or illustrate where exactly unit tests stop and integration tests start?

Is a test that is runnable as an individual method in your IDE, doesn’t require any externally provided setup, runs fast enough that you don’t get distracted, feel exactly like a classic unit test, but spins up a Redis (and cleans up after itself — is that a unit test? As some say if it feels like a unit test, and quacks like a unit test… that’s a totally different discussion.

The Purpose of Tests

Tests are, first and foremost, a tool for developers to enhance productivity. They serve a two-fold purpose: to give you confidence in the quality of your applications at any given moment of time, and to facilitate faster and safer development.

Tests should prevent code breakage, allow for local issue reproduction and fixes, and not obstruct refactoring by breaking when the internals of your code change.

This actually is a frequently overlooked part about good tests: you do want your tests to break when the code’s externally observable behaviour changes.

This prevents you from breaking other’s people parts of the system and them from messing up your code. But you don’t want them to break for “internal code changes”, so you only actually change the tests when functionality changes. This way you don’t get used to changing tests “because they are fragile”, and won’t accidentally change the code behavior and “fix” the tests at the same time wrecking havoc in production.

Tests should also ideally be fast. But rather than having milliseconds value attached, it usually means — quick enough individually to maintain focus during development and as a whole to keep the continuous integration (CI) pipeline flowing smoothly.

So with all the above, doesn’t the preoccupation with labels such as “unit” and “integration” seem inconsequential? If the boundaries between them are so blurred and the ultimate goal of testing transcends these classifications, why do we hold onto them so tightly?

The real measure of a test’s value is not in its label or arbitrary code coverage metrics but in the confidence it provides and its utility in the development process.

In the end, I strongly believe that we’ll have better software if we ask ourselves less “Is this a unit or an integration test?” and more “Does this test meet our needs?”

It’s a very exciting opportunity and I’m thrilled at the impact we can have on the enormous developer community across multiple language ecosystems and thousands of projects. Here are a few reasons AtomicJar is an amazing company to put your efforts in.

Technology

At the heart of the AtomicJar technology is the Testcontainers project and the ideas it popularised initially in the Java ecosystem.

Testcontainers is a collection of libraries that integrate with your tests and provides lightweight, ephemeral instances of common third-party services you need: databases, message queues, text search engines, Kafkas, and Redises, and Mockservers, and if needed even the browsers for your UI tests.

All these services can be easily programmatically managed as containers that are aware of your tests’ lifecycle and turn running your integration tests into bliss.

You can find the details and typical usage patterns on the website: testcontainers.org, but if you haven’t seen it at all here’s a one-liner to awe in delight.

Setting up a Kafka instance programmatically:

KafkaContainer kafka = 
      new KafkaContainer(DockerImageName.parse(
                               "confluentinc/cp-kafka:5.4.3"));

And then you can access it programmatically too with something like kafka.getBootstrapServers(). There’s of course API for every particular type of service that makes sense for them: databases, caches, search engines.

With Testcontainers it’s so easy to create proper integration tests with it and the user experience is so smooth that it’s really easy to fall in love with the technology.

James Ward on Twitter: "I've been using @testcontainers not just for tests but also for local development... And it is AMAZING! / Twitter"

I've been using @testcontainers not just for tests but also for local development... And it is AMAZING!

Here’s what James Ward said about Testcontainers about a year ago, and it’s as valid now as ever.

And trust me, James knows a thing or two about technology, productivity, and developer experience.

Community

Technology and the product are only a part of the equation. What sets AtomicJar apart is the emphasis on the success of the community.

There are currently thousands of users of the testcontainers libraries. They are also not limited to the Java ecosystem, there’re for example:

• testcontainers-java
• testcontainers-go
• testcontainers-python
• testcontainers-rust
• testcontainers-node
• testcontainers-dotnet

You get the point, having better integration tests is not limited to a particular language. All our projects could have better and faster integration tests.

Here’s for example a blogpost by Ricardo Ferreira about using testcontainers to manage Elasticsearch from golang tests.

I’m not an expert in go, but it looks neat, doesn’t it?

As a developer advocate, I’m thrilled to work with the diverse communities of various ecosystems!

If you don’t have enough of those, you can join the Slack workspace for the project and hang out with cool people there.

Company

Last but not least, AtomicJar is a company I see to have a bright future. I have this tendency to trust brilliant engineers, and with Sergei and Richard at the helm, how much more brilliant can it get?

Very often companies market themselves as being for developers by developers. In the case of AtomicJar, I feel it’s really the case. Open source is at the heart of the company, the team understands developers, we even participate in various initiatives like opencollective to support OSS projects.

It is also an excellent opportunity to see a company grow and establish itself from the early stages which is an experience I welcome very-very much.

And since you’ve read so far already, you clearly have a few minutes on your hands. Why not write a new integration test for the project you’re working on? Who knows maybe you can even try a cool library that makes integration tests simpler. 😉

GraalVM 21.2 is released today and in this article we focus on the most visible, important, and exciting updates available in this version.

First things first, GraalVM 21.2 builds are available for download from the usual locations:

• GraalVM
• GraalVM Enterprise

GraalVM consists of several components, and with every release we work hard on bringing improvements to them all. So if you’re interested in a particular component and would like to get a more detailed overview of the changes, please consult the documentation.

Native Image

Let’s start with looking at new and noteworthy in Native Image. Back in June we released the new Gradle and Maven plugins for Native Image with initial JUnit 5 testing support. It simplifies building native images of your applications and allows to run JUnit tests in native image mode to check how your code works there.

Since the initial release there have been two minor ones with various bug fixes, improvements, and cleanups, so if you maintain an application or library that works in Native Image, consider using the two run tests and verify behavior in Native Image!

Another quality of life improvement is that Native Image now automatically removes unnecessary security providers from the image: the reachable security providers are detected by the static analysis. This means the options like --enable-all-security-services are deprecated and will be removed in the future. It is possible to disable the automatic detection completely using -H:-EnableSecurityServicesFeature and register the providers manually as well. You can read more about it in the docs.

One very welcome addition that landed in 21.2 is the implementation of the class pre-definition to support ClassLoader.loadClass calls at run time. Desired classes that need to be loaded at run time must be made available to the static analysis at build time so that they are included in the closed world analysis, but otherwise the code patterns that include loading classes at arbitrary moments of run time are now working in native images just as you'd expected them to.

Another interesting infrastructure enhancement made to GraalVM 21.2 is that native images built with -H:+AllowVMInspection now support JFR events that are written in Java. To record JFR events at run time, JFR support and JFR recording must be enabled with the command line options -XX:+FlightRecorder and -XX:StartFlightRecording. There aren't that many events actually implemented, but the architecture for implementing them or emitting them from the application code is available.

You can try the following example to see how your custom events could look in practice:

Build it into the native image, run with -XX:+FlightRecorder -XX:StartFlightRecording=”filename=recording.jfr”

And you can see how the event looks like in, for example, VisualVM:

Compiler Updates

Every update brings incremental improvements and new optimizations in the compiler which result in gains on some workloads. Over time these gains accumulate and result in significant performance gains. If you have not updated recently, now is a good time to leverage all those improvements. In 21.2 there are a number of interesting optimizations added to the compiler. Let’s start with the ones available in GraalVM Enterprise, available as part of an Oracle Java SE Subscription.

We improved loop limit analysis for counted loops, so the compiler also analyzes the control flow preceding the loop to reason about the induction variables. This can make more uncounted loops, like the example one below, amendable for advanced optimizations.

long i = 0;
  if (end < 1) return;
  do {
      // body
      i++;
  } while (i != end);

Here the compiler can combine the info from before the loop that i is 0 and end ≥ 1 to prove that end > i and use that data for optimizing the loop body.

We also added a novel Strip Mining optimization for non-counted loops, which splits loop iteration into parts, making them easier to optimize later. It is is disabled per default; enable it with the -Dgraal.StripMineNonCountedLoops=true option.

We improved compilation of the code which uses typical StringBuilder patterns, and enhanced support for these patterns in JDK11 based GraalVM builds by making it aware of the compact strings in JDK11.

Then in terms of GraalVM Community Edition, one notable improvement to the compiler is the addition of the Speculative Guard Movement optimization, which tries to move a loop invariant guard, for example, an array bounds check, from inside a loop to outside of the loop. This can improve relevant workloads dramatically.

Also, we improved safe-point elimination mechanisms in long counted loops. The compiler can now eliminate safe-points in loops that have a long induction variable where it can statically prove that the range of the induction variable is Integer.MAX_VALUE - Integer.MIN_VALUE. Consider this for-loop example:

for (long i = Integer.MIN_VALUE; I < Integer.MAX_VALUE; I++) { 
  // body 
}

The compiler can now statically prove i only iterates within integer range even though it is a long. As a result, the integer overflow situation doesn't need to be accounted for and the loop optimizes better.

On top of these there are a few optimizations available in this release not yet enabled by default and considered experimental. One experimental optimization called Write Sinking tries to move writes out of loops. You can enable it in GraalVM Enterprise with -Dgraal.OptWriteMotion=true. Another optimization available in GraalVM Enterprise, but not yet enabled by default is a novel SIMD (Single Instruction Multiple Data) vectorization optimization for sequential code. You can experiment with it by using the -Dgraal.VectorizeSIMD=true option. If you're not ready to experiment yourself, stay tuned — in an upcoming standalone article we're going to explore in detail what it gives you, and how your code can benefit from it.

Polyglot Runtime & Truffle framework

Truffle received a new compilation queuing heuristic, enabled by default. This new heuristic improves the warm-up time of the polyglot runtime on many workloads.

Here’s a brief explanation what it does: imagine the following synthetic piece of JavaScript code is your application. It runs 2 functions in a loop, both of which reach the threshold for the JIT compilation and need to be compiled:

In the previous versions of GraalVM, the algorithm to prioritize compilation worked in the first-come, first-served order. This would result in compiling the lowUsagefunction first, instead of the more beneficial order with highUsage being compiled first.

Now in GraalVM 21.2, the policy is more sophisticated than just the hotness and takes into account the multi-tier settings, compiling for the first tier faster, compilation history and deoptimizations prioritising code previously already determined to be important, and the weighted combination of code hotness and being in active use at the same time. All in all this should result in better warmup for all GraalVM languages.

There are additional configuration options to tweak the heuristic or disable its use completely. Learn more about it in the docs.

Another change is that certain API calls when embedding a polyglot context require a new version of JVMCI, the compiler interface used to plug the compiler to the Java HotSpot VM. The GraalVM distributions for all JDK versions contain the updated JVMCI, but if you’re using GraalVM languages with a different JDK and enable the GraalVM compiler on the module path, make sure to use one of the following JDK versions that include JDK-8264016 for full compatibility.

Otherwise using forced context cancellation (Context.close(true)) or interrupting (Context.interrupt(Duration)) will throw errors. For the best experience, consider using the GraalVM distributions for running your applications or avoid using these APIs. Other possible workarounds are described in the notes.

And since we’re talking about Truffle-related changes, there are some exciting updates in GraalVM 21.2 for projects implementing languages and tools on GraalVM. Truffle libraries can now be prepared for ahead-of-time compilation without prior execution. See the docs for ExportLibrary.useForAOT and the AOT Tutorial for more details.

JavaScript

JavaScript implementation continues to add and update implementations of the most recent proposals like the New Set Methods, experimental operator overloading support, or the RegExp Match Indices proposal. You can find the details on how to enable these in the release notes.

On top of that, Graal.js enhances the development experience with an option to track unhandled promise rejections in a polyglot Context. By default, the option is set to none, and unhandled promise rejections are not tracked, but you can configure and make your development life easier with the js.unhandled-rejections option.

Ruby

As always Ruby experienced a continuous, ongoing stream of compatibility and performance improvements. One very impactful added feature is the precise invalidation for Ruby methods and constants, by using per-name and per-class assumptions. When loading Ruby code, methods are added one by one due to Ruby semantics, and a lot of code is executed while loading files. With per-class assumptions (which is how it behaves in other Ruby implementations and in TruffleRuby prior to this change), it would invalidate all call sites that would call a method of that class. With precise invalidation, it only invalidates call sites that would actually need to call another method for the next call. This improves warmup on the real world code.

Along with these changes, we updated to Ruby 2.7.3, with the exception of resolvstdlib which was not updated (resolv in 2.7.3 has bugs). We also added a new TruffleRuby::ConcurrentMap data structure for use in concurrent-ruby.

For lots of other changes and fixes, check the release notes.

Python

In this release we implemented _pickle as a faster version than the pure Python version, making serialization faster.

Improved support for interoperability with other languages for the dict type to work as you'd expect it to work, which is now using Truffle hash implementation.

As always a lot of work focused on performance improvements especially during warmup and in shared engine configurations!

And there are lots of compatibility improvements too. Check release notes or more details.

LLVM bitcode runtime

There are some C++ related improvements in 21.2. We fixed the issue of the LLVM toolchain not working correctly for C++ on MacOS 11.3. We also added support for C++ virtual calls via cross-language interoperability.

The managed mode in GraalVM Enterprise also got better. We updated musl libcto to version 1.2.2, and improved compatibility with the existing native code bases by adding support for pthreads and pthread synchronization primitives in managed mode.

FastR

FastR continues to work on compatibility, improving its support for packages in 2021–02–01 CRAN snapshot:

• testthat 3.0.1 is partially supported.
• tibble 3.0.6 , vctrs 0.3.6, and data.table 1.13.6 are mostly supported.
• support for dplyr 1.0.3, ggplot 3.3.3, and knitr 1.31 is a work in progress.

If you’re interested in support for a particular package, please reach out!

WebAssembly

The WebAssembly runtime saw lots of compatibility improvements and some bug fixes to pass tests for as many NPM modules that use WebAssembly as currently possible.

Java on Truffle

One of the important things in GraalVM 21.2 for Java on Truffle is a new Hotswap Plugin API, which allows to reload the code without the need for restarting a running application. The API is intended to allow framework developers to have better control over reflecting changes in the application in response to source code edits in your IDE. It’s achieved by setting up appropriate hooks where the main design principle is that you can register various HotSwap listeners that will be fired on specified HotSwap events. For example, it is able to re-run a static initializer, run a generic post HotSwap callback or hooks when implementations for a certain service provider changes.

The most amazing thing about it is that the API consists of normal Java calls — much easier to integrate and maintain than any bytecode manipulation-based solutions.

For more details, check the documentation on the plugin API.

Another very welcome improvement made to 21.2 is the better bytecode dispatch which speeds up the interpreter used in Java on Truffle about 15–30%. Interpreter speed is a very important factor in how fast your application warms up.

21.2 also saw improvements to interoperability for Java on Truffle objects implementing Map, Map.Entry, List, Iterator, or Iterable with the other languages including the Java host code.

Tools

VisualVM got a number of excellent improvements, including support for JDK 17 and allowing functionality to be controlled from command line or other external tools. The latter enables a smooth integration between VisualVM and VSCode with the GraalVM extension installed. You can command VisualVM to profile your application right from the IDE.

VisualVM now can also save a JFR recording from a live Java process, and has a new Lock Contention view in the Profiler tab. So if you’re using VisualVM for your day-to-day profiling needs now it’s more powerful than ever.

Documentation

Last but not least, we restructured the documentation for GraalVM that ends up on the website. It’s now available in the main project repository on GitHub.

This means that it’s easier than ever to contribute to GraalVM and improve the lives of many other developers in the ecosystem. If you notice docs that could use clarification or incompletely describe your favorite features or tuning options, please consider sharing your expertise and helping the project with a pull request! If in doubt, here’s a short guide on how to do that: contributing to the docs.

Note, that the GraalVM Enterprise documentation is available on the docs.oracle.com site.

As with every release, we want to thank the GraalVM community for all the collaboration, feedback, and discussions, and for sharing your stories about how you use GraalVM.

As we mentioned before, the downloads are available, as always, on the website.

Please don’t hesitate to let us know of any and all feedback! There are several channels available to reach the team, pick whichever works for you best: Slack, GitHub, or Twitter, or send us an email.

— GraalVM Team

GraalVM 21.2 with lots of native image usability improvements was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

As with every release, we’re incredibly grateful to the GraalVM community for all the feedback, collaboration, GitHub issues, pull requests, and for spreading the word about GraalVM! You make GraalVM the increasingly successful and ever-improving project it is!

GraalVM 21.1 is available for download from these websites:

• GraalVM Enterprise Edition
• GraalVM Community Edition

In this article we want to highlight some of the most important improvements in GraalVM 21.1. If you’re interested in a particular component and would like to see a detailed list of changes, please consult the 21.1 release notes.

And if your preferred way to learn is videos rather than text, here’s a live stream discussing the updates in GraalVM 21.1:

Platform Updates

Oracle GraalVM Enterprise Edition 21.1 is based on Oracle JDK version 1.8.0_291 and Oracle JDK version 11.0.11. GraalVM Community Edition in 21.1 is based on OpenJDK version 1.8.0_292 and OpenJDK version 11.0.11.

GraalVM 21.1 introduces new experimental binaries based on JDK 16 for both Enterprise and Community editions based on JDK 16.0.1.

The experimental status means that all components in the JDK 16 based binaries are considered experimental regardless what their status is in other distribution versions.

The JIT mode for Java applications is perhaps the most tested capability for these builds, so if you are interested in running your Java applications with the GraalVM compiler or are currently using the JVMCI compiler in any other JDK 16 OpenJDK builds, consider trying out the GraalVM binaries. These include the latest OpenJDK changes and the latest GraalVM compiler changes which is the best of both worlds setup.

Java 16 is the current release of Java and we are looking forward to providing support for the upcoming Java 17 LTS release.

Note that due to the decommissioning of the aging macOS 10.7 build infrastructure, GraalVM Community Edition releases based on JDK 8 are no longer being built.

Node.js included in GraalVM 21.1 has been updated to 14.16.1, which is recommended for most users.

There’s one more significant change regarding Node in GraalVM. As of GraalVM 21.1, Node.js support is no longer included in the base GraalVM download. It’s now a separate component that you can install with the gu install nodejs command. JavaScript support continues to be a part of the base download, it's just the Node.js support that's installable separately. This change is for speed and clarity — it aims to reduce the size of the base GraalVM download, and to reduce confusion among some users who want to use GraalVM primarily as their main JDK.

Compiler Updates

Updates to the compiler are especially exciting because they improve GraalVM across the board since the compiler underpins the performance of all the various languages supported on GraalVM!

In 21.1 there are two particularly interesting compiler improvements:

One new optimization eliminates unneeded memory barriers on sequential volatile writes on x86. Numerous volatile writes sometimes occur in a sequence after the code has been inlined. The GraalVM compiler now omits the memory barrier for all but the last write in the sequence, nicely speeding up methods like ConcurrentHashMap.transfer().

The other main improvement, which can help increase performance on similar workloads, is more of a fix rather than a whole new optimization. In the following example method, also from ConcurrentHashMap, Unsafe is used to get an Object from an array. With this fix, the GraalVM compiler eliminates the cast:

static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {      
  return (Node<K,V>)U.getObjectVolatile(
                      tab,                                        
                      ((long)i << ASHIFT) + ABASE); 
}

Loops Updates

This release includes support in the GraalVM Enterprise compiler for vectorizing loops that have the hashCode-like pattern. Hashcode is often computed with an idiom like: hash = c * hash + array[i] , which the compiler can now recognize and vectorize.

We also want to highlight two new GraalVM Enterprise features related to inverted loops. First, the compiler detects inverted loops as counted loops:

Here’s an example of a tail-counted, inverted:

int i = 0; 
do {    
  // loop body    
  i++; 
} while (i < limit);

Note that the loop limit check is at the end of the loop body. GraalVM Enterprise now detects such loops as counted, enabling them to be analyzed and optimized like all other counted loops making them subject to full unrolling, partial unrolling, guard optimization, and vectorization. This new capability can be disabled with the following option:

-Dgraal.DetectInvertedLoopsAsCounted=false.

We have seen performance improvements of up to 40% for applications with inverted loops in hot code paths! A prominent example of frequent inverted loop usage is the LLVM bitcode runtime in GraalVM. It compiles LLVM IR, and the internal loop representation in Clang often resembles inverted loops.

The second improvement in this regard is a novel loop inversion optimization. This adds compiler support to GraalVM Enterprise to generate inverted loops from regular ones. Inverted loops have superior characteristics for instruction-level parallelism and optimization capabilities compared to regular, head counted loops.

Consider this example loop:

int limit = ...; // e.g. a parameter int i = 0; 
while (i < limit) {   
  array[i] += 10;   
  i++; 
}

Every iteration of this loop has to perform an index bounds check and throw an ArrayIndexOutOfBoundsException if it is above the array length. The guard motion optimization in GraalVM Enterprise will generate an optimized version of the guard that can be hoisted before the loop:

int limit = ...; 
int i = 0; 

// transfer to interpreter to raise ArrayIndexOutOfBoundsException
if (limit >= array.length || limit < 0) deoptimize();  
while (i < limit) { 
  array[i] += 10;   
i++; 
}

The disadvantage of this code is that the guard is checked even if the loop is never entered. It isn’t the best use of time and resources. This could be solved by replicating the check that determines if the loop will be entered, but this is an extra work and increases code size. By inverting the loop, however, we get:

int limit = ...;
int i = 0;
if (i < limit) {
  // landing pad
  if (limit >= array.length || limit < 0) deoptimize();
  do {
    array[i] += 10;
    i++;
  } while (i < limit);
}

This creates a natural landing pad for guard motion and loop invariant expressions before the loop that is only executed if the original loop is executed. We have seen performance improvements of up to 30% for micro benchmarks exercising the inverted loop shape. Not too shabby!

Native Image

As in every release, there are numerous fixed issues and compatibility improvements in Native Image, along with new features.

GraalVM 21.1 adds support for multiple locales in Native Image. Now you can specify at build time which locales should be included in the generated executable. For example, to switch the default locale to German and also include French and English, use -H:DefaultLocale=de -H:IncludeLocales=fr,en. All locales can be included via -H:+IncludeAllLocales. ResourceBundles are included by default for all selected locales, but this can be changed by providing a locale-specific substring when requesting the bundle.

Further improvements — such as updating the Native Image assisted configuration agent to help with locale configurations, and loading bundles from an external storage — are planned for the next release.

We also deprecated the use of the --enable-all-security-services option. It is no longer necessary as security services are now registered automatically when usage is detected by static analysis during build time.

This release improves support for Native Image on Windows. Applications built with Native Image now do file globbing on parameters. Globbing is interpreting standard special characters like * and ? to match the filenames.

There are also other nice additions, like added reporting on the Native Image build in order to produce multiple artifacts, with results written to the <image-name>.build_artifacts.txt file. Also, multiple different Native Image compiled artifacts are can be used in the same process. For example, an application built with Native Image can use a Native Image generated shared library.

Polyglot Runtime

If you’re using any of the Truffle languages — JavaScript, Python, Ruby, R, Webassembly, Java on Truffle, TruffleSqueak, LLVM bitcode, etc. — changes to the polyglot runtime are important to your applications!

The polyglot runtime in GraalVM 21.1 has multi-tier compilation enabled by default. This feature was first introduced in 20.3 as an experimental option. With it enabled, Truffle uses two tiers of compilation for polyglot languages. The first tier is optimized for compilation speed and reuses the GraalVM compiler economy configuration to perform speedy compilations with method inlining of trivial methods only. The second tier compiles with all GraalVM’s compiler optimizations enabled and is performed after the first tier compilation has completed. Our benchmark results show that this improves warmup for most languages significantly.

In the adjacent article we look into more details about multi-tier compilation in GraalVM 21.1 and explore its impact on various benchmarks and Truffle languages.

To support flexibility of the multi-tier compilation, 21.1 also introduces new experimental flags to set the compilation thresholds: --engine.FirstTierCompilationThreshold sets the threshold for the first, and --engine.LastTierCompilationThreshold for the second tier. If multi-tier compilation is disabled, --engine.SingleTierCompilationThreshold may be used. The original existing option, --engine.CompilationThreshold, is now deprecated and will be taken out behind the barn and set free (removed) in a future release.

On top of improving warmup with the multi-tier compilation, this release also includes a new experimental compilation queue implementation inspired by HotSpot. This implementation is not yet enabled by default, but you can try it on your workloads using the --engine.TraversingCompilationQueue option. Give it a whirl. It is expected to reduce warmup time even more.

Your mileage may vary and it all heavily depends on the workload and details of your codebase, but startup and warmup performances of Truffle languages should show significant improvements over previous releases!

For Polyglot Embedding/Guest Language Users

If you’re using Truffle languages from a Java application, the changes listed here may be important for you.

One interesting new capability added in GraalVM 21.1 is an implementation of the guest languages safepoints. Use Context.safepoint() to cooperatively poll thread local actions of a polyglot context while a host method is executed. This allows to check for interruption or cancellation from within the Context.

This release also adds a new experimental sandbox option to GraalVM Enterprise to constrain memory usage of the guest language. Use the --sandbox.MaxHeapMemory=<size> option that controls the maximum heap memory that a guest application can retain during its run. This feature is currently only supported on HotSpot. More information on how to use heap memory limits can be found in the sandbox documentation.

There are three welcome additions to the Truffle polyglot support for data-structures: byte buffer-like, iterator and iterable-like, and map-like data structures! Support for these features in the individual languages may vary as they need to implement the changes as well, but in a nutshell it means the following:

• java.nio.ByteBuffer implementations work like native guest language buffers.
• java.util.Iterator and java.util.Iterable implementations work like guest language iterators.
• java.util.Map implementations are handled to make them look like guest language hash maps.
• guest language iterators and hash maps can be mapped to Java ones with Value.as(Iterator.class), Value.as(Map.class).
• Value class API includes new methods for accessing these new data structures: Value.hasBufferElements(), Value.isIterator() and Value.hasIterator(), and Value.hasHashEntries().

Of course, these features can be controlled with the HostAccess.Builder methods allowMapAccess, allowBufferAccess, allowIteratorAccess, and allowIterableAccess. This means that if a language implementation supports it, you can pass a Java Map to the context and access its entries as if it was a native guest language map.

JavaScript

As we mentioned above in the platform updates, the version of Node.js GraalVM supports has been updated to 14.16.1. In this release, the node and npm binaries are not included in the base download, but are instead available to be installed separately.

Installing the Node.js component is done using the gu utility like for all other optional components: gu install nodejs

[opc@ol8-demo 21.1]$ gu install nodejs
Downloading: Component catalog from www.graalvm.org
Processing Component: Graal.nodejs
Downloading: Component nodejs: Graal.nodejs  from github.com
Installing new component: Graal.nodejs (org.graalvm.nodejs, version 21.1.0)
... 

Note that if you want to use node for running polyglot programs not in the JVM mode, which is turned on by the --jvm command line option, then you need to rebuild the polyglot shared library to include all languages you want to have access to. This can be done by running gu rebuild images or following the instructions in the gu install output. In JVM mode, all installed languages can be dynamically loaded so rebuilding is not necessary.

JavaScript in GraalVM 21.1 includes Truffle’s support for iterators, iterables, and byte buffers, which allows JavaScript iterators to be used via the Value API hasIterator(), getIterator(), hasIteratorNextElement(), getIteratorNextElement(); iterable objects from other languages to be iterated in GraalVM's JavaScript runtime, e.g., via for-of loops and vice versa; for the host ByteBuffers and buffers from other languages to be used with JavaScript typed arrays, e.g., new Uint8Array(foreignBuffer), and DataView without copying; and to access ArrayBuffers via the Value API: readBuffer*, writeBuffer*.

Support for Maps is also included so you can iterate them with for in/ofloops and new Map(hash), Array.from(hash), etc. Even better if the --js.foreign-hash-properties option is enabled (which it is by default), then foreign hash maps can also be accessed using hash[key], hash.key, {...hash}. With this support, the following example now works:

It prints the wonderfully exciting:

[opc@ol8-demo 21.1]$ javac Main.java && java Main 
GraalVM 
21.1 
Map(2) {"hello" => "world", 1 => 42}; world

On top of all of these excellent improvements, this release also adds the first experimental version of the WebAssembly JavaScript Interface, which allows invoking WebAssembly programs from within JavaScript. This feature is enabled by the --js.webassembly option.

Ruby

As with every release, GraalVM 21.1 reflects a solid amount of Ruby compatibility and performance work, including more complete support of Ruby 2.7 (remaining work can be seen in the GitHub issue).

Multi-tier compilation is now enabled by default, which significantly improves warmup. Other items — checks for recursion, random number generation, some cases of using class variables, irb, and pasting code into irb — all saw improvements in this release as well.

GraalVM 21.1 also includes improved support for C extensions. Installing gems which use C extensions that link to static libraries now generally work when prepending the GraalVM LLVM toolchain to your PATH. With this release, GraalVM now defaults to the vendored libxml2 and libxslt gems when installing nokogiri, similar to CRuby, which means the corresponding system packages are no longer needed.

Also, if you’re using standalone builds of TruffleRuby, note that it is now based on JDK 11, up from JDK 8 which it used previously.

Python

One of the more significant improvements in GraalVM 21.1 for Python is the enhanced support for Java subclassing and new interop APIs for better Jython migration path. Iteration over Python types from Java, catching and re-throwing Java exceptions in Python code, as well as implementing Java abstract classes and interfaces from Python are often-requested Jython features that GraalVM now provides, making the migration easier.

Another very exciting addition is SSL support. Now you can install packages and their dependencies with pip just as with CPython:

$ graalpython -m venv env 
We're not using symlinks in a Graal Python venv 

$ source env/bin/activate 

$ pip install pygal 
Collecting pygal   
Downloading pygal-2.4.0-py2.py3-none-any.whl (127 kB)      
|████████████████████████████████| 127 kB 983 kB/s 
Looking for Graal Python patches for pygal 
Installing collected packages: pygal 
Looking for Graal Python patches for pygal 
Successfully installed pygal-2.4.0

There’s also a new completely native backend for Posix API, which provides better performance and improved compatibility for filesystem access.

And we wrap up the list of exciting new features in GraalVM 21.1’s Python support with the addition of multi-threading with Global Interpreter Lock (GIL). GraalPython supports multi-threading to the same extent as CPython, that is, there is only concurrency, not parallelism for most workloads.

LLVM bitcode runtime

There are, as usual, oodles of performance improvements and compatibility fixes for the LLVM runtime, but in 21.1, there are also a few new features.

Pointers to foreign “buffer-like” objects, for example, JavaScript’s ArrayBuffer, can be transparently accessed like native buffers.

GraalVM now supports loading bitcode modules with regular dlopen in addition to the Polyglot API.

The option was added to support building GraalVM or native executables with “native mode” completely removed, making --llvm.managed mode the only available option. This improves security in certain scenarios.

FastR

In this release, GraalVM’s R implementation mostly saw compatibility work.

GraalVM 21.1 upgrades FastR to R version 4.0.3, which means FastR runtime mostly compatible with R 4.0.3. It also migrated to new versions of the base and recommended packages, and implements some of the new features of R 4.0.3. See the changelog for all the details.

We also upgraded the CRAN snapshot, used by default by install.packages, to 2021-02-01. Support for new versions of some of the most popular packages on FastR is a work in progress that will improve in future releases with known issues in in dplyr 1.0.3, ggplot 3.3.3, and knitr 1.31.

WebAssembly

GraalVM 21.1 has two main improvement themes: compatibility and performance. Following that philosophy, JavaScript and WebAssembly are now integrated much better than before, now allowing JavaScript to invoke WebAssembly. Basic WASI functions are now implemented, which allows manipulating files and accessing the file system through the Truffle file-system layer… and performance results are incredible!

Besides improving the speed of the standalone GraalWasm launcher and peak performance of WebAssembly on GraalVM in general, the main highlight is the more that 10x performance improvement of the interpreter, which should be most evident in short-running programs or in code that’s invoked just a few times, not enough to trigger JIT compilation. This is not a drill. We repeat — 10x performance improvement!

Java on Truffle

The GraalVM 21.0 release was the first for Java on Truffle. Since then, we’ve concentrated on compatibility and making sure it’s useful for running typical applications in typical development scenarios.

For example, we fixed a massive slowdown when instruments are enabled, so debugging your application on Java on Truffle doesn’t feel slow anymore. It was not just a single issue, but a number of edge cases in the Java Debug Wire Protocol (JDWP) support that required fixing, and it was all worth it, speeding up applications with the debugger enabled sometimes by a ridiculous 200x!

We also added support for signal handlers, which means that shutdown hooks registered in the application now run as expected when an application stops.

Work always continues on improving enhanced HotSwap capabilities. For example, as of this release, reflective access and MethodHandles now follow method changes.

Tools

Tooling is a very important part of the GraalVM Ecosystem. In every release we’re trying to improve the developer experience by improving the tools that are part of the GraalVM distribution, including the debugger and profilers, etc.. GraalVM 21.1 is no exception.

For example, VisualVM now also works on JDK 16 and has support for running on Apple M1 chips.

We’re happy to announce the new version of the VS Code GraalVM Extensions, which includes a collection of features to make working with GraalVM, Java, and Micronaut applications easier:

• Added unit test results visualization

• Improved Micronaut support: YAML support and content assistance for configuration files, and more Java code editing features

• Added new supported refactorings for Java code
• Added support for Docker build commands for Micronaut projects

Whew!

While this is a much longer post than we typically write for a release, these are still only some of the exciting improvements in GraalVM 21.1!

Again, as always, the downloads are available on the website.

Please don’t hesitate to send us any and all feedback! There are several channels available to reach the team; pick whichever works best for you: Slack, GitHub, or Twitter! We’re always happy to hear from you!

Until next time!

— GraalVM Team

Faster warmup, smaller downloads, JDK 16 was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the recent winter holidays break this release was in development for a brief time, however it still offers a number of improvements and new exciting features for the whole GraalVM ecosystem.

As with every release, we’re greatly thankful to the wonderful GraalVM community for all the feedback, collaboration and the discussions around the issues, sending pull requests, and last but not least spreading the word about the GraalVM project and how it helps your project. Together, we make GraalVM extraordinary!

GraalVM 21.0 is available for downloading right now:

• GraalVM
• GraalVM Enterprise

In this article we want to talk about some of the most notable changes in GraalVM 21.0. There are many components to GraalVM and every release brings improvements and fixes to all of them. So for a more detailed list of changes, please consider the release notes on the website or the change logs of the individual components.

Platform Updates

As usual, the release bumps up the version of the JDK used for the GraalVM builds. GraalVM Community Edition in 21.0 is based on OpenJDK version 1.8.0_282 and OpenJDK version 11.0.10, and the GraalVM Enterprise on Oracle JDK version 1.8.0_281 and Oracle JDK version 11.0.10.

Java on Truffle

The most exciting addition in GraalVM 21.0 is the new component which implements Java on Truffle. Java on Truffle is a JVM, realized with the Truffle framework.

Java on Truffle is currently marked as experimental. However, even in this initial release state it offers very interesting capabilities and makes Java (and other JVM languages) possible to run through the infrastructure that powers all other GraalVM languages.

Install it with gu install espresso, and give it a spin by running your favourite Java app with java -truffle.

Read more about Java on Truffle in this adjacent article providing more details, motivation, and use cases for how you can experiment with using Java on Truffle now.

Native Image

One of the things possible now is the use of Java serialization in the native image binaries. Serialization usage needs to be configured, just like the other dynamic features, and classes which can be serialised/deserialized needs to be known during the build time. The configuration can be generated using the assisted configuration withjavaagent, so you don’t have to create it from scratch.

Consider, for example, if you have a class like this:

It serializes, deserializes and prints the Fibonacci numbers. You can compile and run it withjavaagent:

javac Main.java
java -agentlib:native-image-agent=config-output-dir=config/META-INF/native-image Main

Now in the config directory, we can see the JSON file showing which classes will be included for serialisation:

cat config/META-INF/native-image/serialization-config.json 
[{   "name":"java.lang.Long"        },   
 {   "name":"java.lang.Number"      },   
 {   "name":"java.util.ArrayList"   } 
]

All that is left to build the native image is just running the command: native-image -cp .:config Main. And voila, the list of the Fibonacci numbers will be serialized/deserialized when you run the result.

In addition to this very important change that brings native image capabilities to more Java programs much easier than before, 21.0 has an improved method handle invocation support. Most of the use cases of method handles should be working now. They do require the configuration, but the tracing agent can also provide it for you.

Speaking of the configuration agent with the configuration provided by it, you can build native images of the AWT and Swing applications on Linux (experimental). Other platforms aren’t supported yet, but it’s an excellent first step.

Truffle

Truffle added the HostCompilerDirectives annotation for directives that guide the optimizations in host compilations of the Truffle interpreters:

• HostCompilerDirectives.BytecodeInterpreterSwitchto denote methods that contain the instruction-dispatch switch in bytecode interpreters
• HostCompilerDirectives.BytecodeInterpreterSwitchBoundary to denote methods that do not need to be inlined into the bytecode interpreter switch.

JavaScript

Node.js in the distributions of GraalVM got updated to 12.20.1.

Compatibility is always priority number one, and this release enables the following ECMAScript 2021 mode/features by default:

• Class fields
• Promise.any
• String.prototype.replaceAll
• Logical Assignment Operators

Even more, if you would run the JavaScript engine in the ECMAScript 2022 mode enabled by the --js.ecmascript-version=2022 option, you even get the implementation of the relative indexing method proposal.

Ruby

In GraalVM 21.0, the Ruby implementation now targets compatibility with Ruby 2.7.2. Most Ruby 2.7 features and changes are implemented (see this GitHub issue for the details).

In addition to that, in the short time this release was in development, there were some performance improvements, notably methods like MatchData#length, Array#sample, String#inspect, are now more efficient.

A few issues around the $~ special variable were also fixed.

Some interop method under Truffle::Interop have been renamed to match better the naming of InteropLibrary (#2139).

Note that the new IRB version is quite slow when copy/pasting code into it. This is due to an inefficient io/console implementation which will be addressed in the next release. A workaround is to use irb --readline, which disables some IRB features but is much faster for copy/pasting code.

Python

The team continues to work on the compatibility both with Python native libraries and the Jython implementation.

For example, 21.0 saw the addition of the jarray module for compatibility with Jython. It also sports fixes to avoid possible memory leaks and crashes when running NumPy in certain setups and improved support for Pandas.

For more details about the performance updates, and other fixes, check out the changelog in the repo.

LLVM bitcode runtime

One of the major areas for improvement for the LLVM bitcode runtime implementation is warmup. In 21.0 we improved not only the AST sharing — sharing the internal representation of the program among several contexts in a single engine, but also introduced support for the auxiliary engine caching. On top of what the AST sharing provides, the auxiliary engine caching allows persisting of shared code across process boundaries.

GraalWASM

The Webassembly interpreter sometimes flies under the radar, but there’s always active work happening to make it better, faster, and more secure. In 21.0 we optimized the Graalwasm interpreter making the warmup better and overall peak performance of interpreting WebAssembly up to 20x faster. We also pass most of the official WebAssembly specification suite now, and we are working on fixing several minor remaining edge-cases.

Tools

Since GraalVM 21.0 the gu utility becomes more powerful and can be used to update your local GraalVM installation to a newer version, or upgrade from the Community to Enterprise Edition. Please refer to the documentation for more details.

Also, as a part of the GraalVM 21.0 release, we’re happy to announce the GraalVM Extension Pack for Visual Studio Code. While being a Technology Preview release, it already provides many features to boost your Java 8+, JavaScript, Python, Ruby, R, and Micronaut productivity in the VS Code environment. The Extension Pack is immediately available on the Visual Studio Code Marketplace and ready to be installed right from your VS Code — just type GraalVM in the Extensions: Marketplace view, select the GraalVM Extension Pack and click the Install button. While installing, you can read more details on the VS Code extensions in a separate article.

Note that these are only a part of the improvements in the GraalVM 21.0! Please read a more detailed outline of the new and noteworthy features in the release notes, and for the components you’re most interested in the changelogs are an invaluable source of information!

As we mentioned before, the downloads are available as always for GraalVM 20.3.1 and GraalVM Enterprise 20.3.1.

Even if you don’t plan to upgrade right now, which you should, grab the binaries and try Java on Truffle, it is a really cool addition to the ecosystem.

Please don’t hesitate to let us know on any and all feedback! There are several channels available to reach the team, pick whichever works for you best: Slack, GitHub, or Twitter!

— GraalVM Team

GraalVM 21.0: Introducing a New Way to Run Java was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Up until now, GraalVM has offered two ways to run Java programs: using the Java HotSpot VM with the GraalVM JIT (just-in-time) compiler, and compiled to a native executable using GraalVM Native Image.

Today, we’re happy to announce a new way to run Java on GraalVM. GraalVM 21.0 introduces a new installable component, named espresso, which provides a JVM implementation written in Java.

Espresso makes it possible to run Java code via the Truffle framework elevating Java to the level of the other languages supported on GraalVM.

Try it out

Trying Java on Truffle out is extraordinary straightforward. It is available as a component installable into a base GraalVM distribution with a gu command.

gu install espresso
gu install -L espresso-installable.jar # if downloaded manually

After the installation to run your favorite app on Java on Truffle you just need to pass -truffle to the java command.

java -truffle -jar myApp.jar

Download Java on Truffle and give it a spin! There are some example apps with the instructions that illustrate the particular capabilities of Java on Truffle.

Note that current raw performance of Java on Truffle isn’t representative of what it will be capable of in the near future. The peak performance is several times lower than running the same code in the usual JIT mode. The warmup also hasn’t been optimized yet. We focused in this initial release entirely on the functionality, compatibility, and making Java on Truffle open source available for a broader community.

Expect performance, both warmup and peak performance to increase rapidly in each of our upcoming 21.x releases.

Let’s now look in more details what Java on Truffle is, explore some notable use cases where it can help you, and try to place the project into the larger GraalVM and Java ecosystems.

Java on Truffle

Java on Truffle is a JVM implemented using the Truffle language implementation framework. It provides all core components of a Java virtual machine:

• Bytecode interpreter
• Bytecode verifier
• Single-pass .class file parser
• Simple object model
• Java Native Interface (JNI) implementation in Java
• Virtual Machine Implementation in Java
• Java Debug Wire Protocol (JDWP)

A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development.

What it can do is run Java programs. Well, programs written in other JVM languages too of course. As you can see from the list above, it also supports the debug protocol, so you can debug Java applications using it too.

Java on Truffle is available for both Java 8 and Java 11 based GraalVM distributions, so technically you can use it as a replacement for the JVM of your choice. Java on Truffle is currently experimental and not very fast yet, so it is not recommended for production workloads today, but let’s explore what you can get from running applications with Java on Truffle.

Java on Java

As we mentioned previously Java on Truffle is implemented in Java. It’s a virtual machine implementation, so in order to actually run Java code it needs access to the class library and the native libraries and methods JDK provides. Java on Truffle reuses the JARs and native libraries from the GraalVM distribution.

Being implemented in Java and being able to run Java gives Java on Truffle a very interesting property: it can run itself. Indeed, Java on Truffle is a metacircular VM, it can run itself several levels deep (albeit slower and slower every time).

Being a Java program gives a number of advantages. One of them is ability to be compiled to the native executable with the native image, we’ll explore an interesting use case for that in the following chapter.

Another advantage is that the code is nice, familiar and understandable to Java developers. Consider going to the GitHub repository and looking at the source code for it. Your day-to-day tools work for it, your IDE supports it, you can explore the code base the same way you explore any other Java dependecies. This transparency and familiarity should allow Java on Truffle be efficient at rapidly changing to the better.

Embedding 11 in 8

Java on Truffle is an actual JVM, and it’s also a Java program, which means you can run it within another Java program. This opens very interesting avenues for compartmentalisation of different components in your applications. For example, if you point Java on Truffle to a JDK11 distribution it can run Java 11. With access to Java 8, it becomes Java 8. When you have both distributions available, you can run Java on Truffle in the context of a Java 8 app and use it to run Java 11 byte code, and vice versa. If there’s a library that is only available for Java 8, you can migrate to a newer base JDK and still run that particular library, with some programmatic efforts to establish the interoperability, in the compatible JDK 8 within the same Java process.

Mixing AOT and JIT

Since Java on Truffle, Truffle, the GraalVM compiler and all other necessary components to run Java on Truffle efficiently are all written in Java, it is possible to build a native image executable with the infrastructure to run Java on Truffle.

This means that you can take a Java app, build a JVM into it, and then run that app either on a JVM or as a native image. Note that in the latter case, Java on Truffle can actually execute arbitrary Java code which doesn’t necessarily need to be known at the build time.

That’s right, Java on Truffle can bring the JIT compiler and the dynamic Java runtime to an ahead-of-time compiled binary.

We’ve prepared a sample application to illustrate this concept. There’s a JShell implementation example that takes a normal JShell app, which consists of two separate parts: frontend CLI app and the backend computation engine, and replaces the latter with the Java on Truffle implementation.

You can also follow this demo in a video tutorial:

It actually very neatly reuses all the classes from the original implementation by just loading them. So the original part of the sample application is the “glue” code that connects the host Java part to the Java on Truffle part of the app.

The sample can be compiled as a native executable, resulting in a nice binary that starts faster than the usual JShell because of the native executable performance characteristics and still can execute the Java code we throw at it.

Here’s a screenshot of the Tetris game loaded and started from the JShell implemented with Java on Truffle.

Mixing AOT and JIT is a fascinating option for applications that cannot leverage the native image performance improvements because their functionality depends on dynamic code which does not work easily with Native Image.

Advanced class redefinition

Another really cool feature where Java on Truffle is more powerful than HotSpot is the enhanced Hot Swap ability — changing classes at runtime during a debugging session.

As of GraalVM 21.0 the following changes are supported:

1. Add and remove methods
2. Add and remove constructors
3. Add and remove methods from interfaces
4. Change access modifiers of methods
5. Change access modifiers of constructors
6. Changes to Lambdas
7. Add new anonymous inner classes
8. Remove anonymous inner classes

What will make hot swap even more powerful is the ability to make changes to class fields. It’s in the works and will be added in a future release.

The setup is the same as with HotSpot: you start the debugger, change the code, recompile the class, hit “Reload the classes” in your IDE debugger and resume the program with the new code running next time the changed class is used.

Follow this demo to see the enhanced HotSwap feature in action:

GraalVM ecosystem support

Java on Truffle benefits out of the box from the developer tooling support that GraalVM languages get from the Truffle framework.

For example, you can run your application with some java -truffle --cpusampler and have the sampling profiler run on your code. You can enable the tracing profiler or memory tracer to tell you which parts of the code generate more memory pressure than others.

Another facet of the ecosystem is the supported languages. Java on Truffle allows you to create polyglot programs where different components are written in different languages. The details about how to load code written in other languages, export and import objects between languages, and so on are a little bit more involved than the scope of the current article, but details can be found from the docs.

Next steps

GraalVM 21.0 is the initial release of Java on Truffle. It’s an experimental component right now and there are major improvements planned for it in upcoming releases.

There are many things to improve, from supporting javaagents, to having a better implementation of the interop protocol with other languages, major performance improvements, and so on.

We’ll be working on these and other improvement, and would be absolutely thrilled to hear any and all feedback, feature requests, potential use cases, discovered issues, and shortcomings of the current version. You can share your feedback via Slack, GitHub, or Twitter. To get started, head to graalvm.org/java-on-truffle.

Java on Truffle is a new and very exciting way to run your Java code. Take a look and consider the possibilities!

Java on Truffle — Going Fully Metacircular was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Find more recent quick references here.

There are three main ways how GraalVM can help with Java applications: making them faster by using the state-of-the-art JIT compiler, compiling them into standalone native executables with instant startup and low memory consumption, and enhancing them with libraries or code in other supported languages.

This quick reference is a one-page short summary of what GraalVM can do and the key options and commands to illustrate its capabilities.

You can download and print it. It fits neatly on an A4 paper, so you can hang it in the office and use it as a reminder of what GraalVM can do and which options turn it on. Be sure to grab the pdf version for printing so it looks neat and sharp. Note that if your printer is more comfortable with the US letter paper formats please make sure to get this version, it’ll look better.

In this post, we’ll go over the information in the quick reference and describe it in more detail.

The first part is focused on running Java applications. Foremost, it’s good to remember that the GraalVM distributions contain a JDK with all the usual JDK tools, meaning you can use GraalVM as your JDK. For example, compiling the Java source code with the javac utility:

javac MyApp.java

Naturally, you can also use GraalVM to run your Java applications or any other JVM languages. In addition to being able to run Java, GraalVM benefits from its powerful just-in-time (JIT) compiler and achieves state-of-the-art peak performance to often run them faster than other JDKs.

java -jar MyApp.jar

When running Java applications just-in-time with GraalVM, the underlying JVM is the usual Java Hotspot (tm) VM, which means that most of the configuration options are equivalent, for example, specifying the classpath for your application works like this:

java -cp target/myapp.jar com.example.Main

The GraalVM compiler is normally run in the precompiled to a native shared library mode. But its code is written in Java and it can be used as a JAR file, which results in a slightly different performance profile: using heap memory for the compilation at the expense of the longer warmup (for example, Java code of the compiler needs to compile). The following option configures which mode you want to run in (enabled + by default):

-XX:+-UseJVMCINativeLibrary

In addition to running the compiler as a JAR or a native library, you can specify the configuration for the optimizations by picking the economy for faster warmup, and enterprise for the best peak performance (requires GraalVM Enterprise of course).

-Dgraal.CompilerConfiguration=enterprise|community|economy

The JIT compiler impact can be dramatic speeding up the applications quite a lot, but sometimes it’s unclear whether the compiler is working, whether the code actually reaches the top tier, and which methods get to the compiler.

-Dgraal.PrintCompilation=true

In addition to looking at the logs you can enable more debug output, for example, to print the compiler graphs to analyze them for finding additional optimization opportunities:

-Dgraal.Dump=:2

And of course, other features of the JVM work with GraalVM too. For example, you can attach a Java agent that will instrument the code, generate classes at runtime, and other Java “agenty” things. Both the Java-based agents and the native agents work. One notable example would be the assisted configuration agent for simplifying native image builds.

-javaagent:path/to/jar.jar

-agentlib:path/to/native/agent

The second major advantage of using GraalVM is its Native Image capabilities: compiling your application ahead-of-time into a native binary.

Update: We’ve published a separate quick reference for the native-image, please check it out: Native Image quick reference.

In order to use that you need to install the native-image component. One way to do this is to download the component’s JAR file for your GraalVM distribution and run the following:

gu install -L native-image.jar

Then you can use the installed native-image utility to prepare the native binary of your application:

native-image [options] MyClass

Alternatively, you can use the JAR file syntax similar to the java command.

native-image -jar MyApp.jar

Run the resulting binary like any executable file:

./myApp

If instead of the executable you would like to build a shared library, you can do that by passing the --shared option. You need to mark the methods to be exposed with the @CEntryPoint annotation, but a more detailed exploration of this topic is beyond the scope of this article.

--shared

Another very useful possibility is to build statically linked binaries where the OS libraries like libc are linked into the executable. It’s even possible to pick which libc implementation to use. glibc is used by default, muslc is an option, for which you need to prepare the build environment a bit.

--static --libc=muslc

It is possible to include the infrastructure for running Truffle-based languages: JavaScript, Ruby, Python, R, and so on. This will include the interpreter for the language, the Truffle framework, and the JIT compiler, so the code can be compiled at runtime for faster execution.

For example, each of these will include the support for the corresponding language:

--language:js
--language:python
--language:llvm
--language:ruby

--language:js

Another fascinating capability is the profile-guided optimizations for the native image executables. You can generate an instrumented binary, apply relevant workloads to it, record the profile of the code executed similar to what JIT does, and use those profiles to build the production binary.

native-image — pgo-instrument MyApp
./myApp
native-image — pgo profile.iprof MyApp

And, if you’d like to have more visibility into what happens during the native image build process, for example, trying to understand the class chain through which a class got initialized, you can use a selection of the helpful options.

Tracing the initialization path to a certain class is enabled by the following one:

-H:+TraceClassInitialization=package.class.Name

The native image build is a Java process so you can put a breakpoint into code and attach a debugger to it to have full visibility into what’s happening.

--debug-attach=[port]

In addition to these, there are a ton of other useful options to configure the native image build and the runtime behavior, which we’ll explore in the future, but you can get a gist of what’s available using the expert help option:

--expert-options-all

The third major advantage GraalVM gives you is a polyglot runtime, capable of running several languages, and it includes the Node.js platform powered by GraalVM’s engine for JavaScript. So, if you have a node application, you can run it by calling the node command.

node myApp.js

On top of that there are a number of language launchers that you can use for running programs in the supported languages:

js myApp.js
graalpython myApp.py
ruby myApp.rb
R myApp.r
lli myApp

The launchers, including node, are by default run in the native mode, where the interpreter is compiled as a native image binary. So, to enable interoperability with the JVM to use Java classes, use the --jvm option and for other languages --polyglot:

--polyglot --jvm

The language engines come with a number of features to limit the number of resources, like, for example, the amount of time in milliseconds the language context can run:

--sandbox.MaxCPUTime=Nms

And last but not least, the GraalVM languages have support for common developer tooling out-of-the-box. This is one of the most exciting parts of the whole GraalVM ecosystem — implement a language interpreter fixing the semantics of the language and get a powerful virtual machine, a selection of GC algorithms, a debugger, a profiler, a memory analyzer, and other tools for free.

Specify the following options to enable, respectively, the debugger based on the Chrome DevTools debugger, the sampling profiler, the tracing profiler, and the memory analyzer:

--inspect
--cpusampler
--cputracer
--memsampler

Conclusion

GraalVM is a versatile project offering many interesting capabilities which you can use for your applications, be they in Java, JVM languages, JavaScript, Ruby, Python, R, and others.

From using a better just-in-time compiler to building native executables of your applications to running components in different languages — you can use GraalVM today.

In this quick reference, we tried to outline the most frequently used options that describe the different capabilities of GraalVM.

Download it, print it out, and pin it on the wall. Hopefully, it’ll keep reminding you about how interesting the GraalVM project is even if you currently only using a fraction of what it can offer.

And while you’re at it, get the GraalVM distribution and try a few things from the quick reference like running your Java apps faster, making microservices more cloud friendly with native images, or enhancing your apps with libraries in other languages!

GraalVM quick reference was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we’re happy to announce the GraalVM 20.3.0 release. This is the final feature release of 2020 and if you’re running GraalVM 20.x we recommend taking a look and updating to 20.3. It is also the first long-term support (LTS) release for GraalVM Enterprise. If you’re running one of the 19.x releases or earlier 20.x releases please consider upgrading to 20.3.0 in the near future.

As with every release, we’re greatly thankful to the wonderful GraalVM community for all the feedback, for the collaboration and the discussions of the issues, for sending pull requests and updates to the docs, and last but not least, for spreading the word about the GraalVM project and how it helps your project. Together we make the GraalVM ecosystem extraordinary!

You can download GraalVM 20.3.0 right now:

• GraalVM Community Edition
• GraalVM Enterprise Edition

In this article we want to highlight some of the most notable changes in GraalVM 20.3.0. There are many components in GraalVM and every release brings improvements and fixes to all of them. So for a more detailed list of changes please refer to the release notes.

Platform updates

The GraalVM compiler is at the heart of the GraalVM project: it allows GraalVM to show the best results for Java benchmarks; it’s used for the ahead-of-time compilation when building native images; it’s used to optimize the performance of languages running on the Truffle language implementation framework. So all updates to the compiler are extremely important and impact almost all projects in the GraalVM ecosystem.

GraalVM 20.3 brought a number of noteworthy improvements to the compiler. 20.3.0 enhanced the heuristics that help simulation-based loop peeling in GraalVM Enterprise specifically for the cases where objects in the array are lazily initialized in the first iteration of the loop and used later. Because of this, some Python microbenchmarks saw performance improvement up to 40%. Speaking of arrays, the code generation for initializing newly allocated arrays improved and we corrected the corner cases where certain large array allocations (8–128MB large) were being initialized twice. Another particularly interesting change is in the area of the advanced code duplication optimization in GraalVM Enterprise 20.3.0. This release addresses several misclassifications in the heuristic for duplication. The result is a peak performance improvement of up to 17% on some LLVM bitcode workloads and a 5% increase on relevant Java workloads.

Introduced in a previous release,libgraal dramatically improved the compilation speed of the GraalVM compiler. However, a small amount of class loading was still performed during its initialization. This was visible in the warmup curves of micro benchmarks that had very short iterations. For example, on the NBody benchmark from the "Are We Fast Yet?" benchmark suite, the first 2 benchmark iterations took ~110 milliseconds on libgraal compared to 45 milliseconds on C2. This class loading has now been eliminated from libgraal or delayed until a point after libgraal initialization. A secondary benefit of eliminating this class loading is that it fixed problems related to VM assumptions about the JIT compiler not loading classes.

Individual optimizations and better heuristics don’t always improve all workloads, often they are only marginally better for some. But the continuous addition of small incremental changes does pay off in the long run. Here’s a graph illustrating the progress of 20.3.0 over last year’s 19.3.0 release:

Note that last year’s performance was the state-of-the-art for these workloads showing world-class results. The fact that 20.3 improves on these result is what makes the performance even more impressive.

Native Image

GraalVM Native Image is a very versatile technology supporting cloud deployments, CLI tools, and deployments on embedded and mobile devices.

In 20.3.0 Native Image improved its container awareness: on Linux, resource limits like the processor count and available memory size are read from cgroup V1and V2 configurations. The processor count can also be overridden on the command line using the option -XX:ActiveProcessorCount=.

The G1 garbage collector available in GraalVM Enterprise with the Java HotSpot VM is now also supported in native executables generated by Native Image. G1 now also supports performance counters when the image is built with -H:+AllowVMInspection. It can be enabled at build time using the new simplified and more descriptive option --gc=G1

Isolated compilation is now available in the Community Edition and separates Truffle applications and the runtime compiler from each other, which improves performance by reducing interference between them such as with garbage collection.

The options to enable and disable assertions now support the full syntax to specify package and class names. Assertions need to be configured at image build time, using the options -ea / -da / -esa / -dsa. The definition of "system assertions" is expanded to not only include assertions in the JDK, but also in the Substrate VM runtime system, for example the garbage collector.

This release also brings many small performance and memory footprint optimizations. In particular, a new implementation of type checks improves the performance of Class.isInstance and Class.isAssignableFrom with less type data in the image heap.

Thanks to a collaborative community effort, basic debug info generation is now also available on Windows.

As in every release, we fixed a lot of issues reported on GitHub. One notable example, is the issue where some native image executables were not compressing correctly with the UPX utility. The ratio of compression varies based on the particular project, but it often leads to 60–70% smaller executables for microservice application examples.

Language Implementation Framework (Truffle)

The Truffle Language Implementation Framework underpins all the non-JVM native languages running on GraalVM. In 20.3.0 one of the major themes for Truffle was a focus on improving warmup: how quickly programs become fast. There were three most significant changes that address the warmup. 20.3.0 enabled by default the elastic allocation of Truffle compiler threads depending on the number of available processors. The previous behavior of using 1 or 2 compiler threads, can be explicitly enabled with --engine.CompilerThreads=0.

If you’re using one of the languages GraalVM supports: JavaScript, Ruby, Python, R, or running LLVM bitcode — please try the new release, it can significantly improve the warmup.

If you are embedding these languages, for example in a Java application, there are important improvements in 20.3.0. For example, we added the Context.interrupt(Duration) API to interrupt a polyglot Context execution. The interrupt is non-destructive meaning that the polyglot Context can still be used for further execution.

And GraalVM Enterprise introduced experimental sandbox resource limits. Using the options like:

• sandbox.MaxStatements=<long> to limit the maximum number of statements.
• sandbox.MaxCPUTime=1000ms to limit the total maximum CPU time that is spent running the application.
• sandbox.MaxThreads=<int> - to limit the number of threads that can be concurrently used by a context.

We’ll explore the sandboxing limits in more detail in an upcoming article specifically about it.

JavaScript

The supported Node.js version in GraalVM 20.3.0 was updated to 12.18.4.

JavaScript also saw a number of improvements to Nashorn compatibility mode, including:

• enabling low precedence lossy number, string-to-boolean, and number-to-boolean conversions.
• fixing the field, getter, and setter access order to mimic Nashorn.
• fixing Java.extend to respect HostAccess.Builder.allowImplementation limits.

The ability to set JavaScript prototypes for foreign objects mimicking JavaScript types became supported in 20.3.0, so the option to enable that got renamed to js.foreign-object-prototype.

Ruby

In every release, TruffleRuby comes with a ton of compatibility fixes and performance improvements.

On top of the changes focusing on warmup improvements that Truffle brings to all languages, Ruby in 20.3.0 includes various warmup improvements, notably much less splitting and more operations are being done inline, without a call. This should result in reaching peak performance faster.

Python

The compatibility of GraalVM’s Python implementation continues to improve. The 20.3.0 release contains many fixes to pass the unit tests of standard library types and modules: complex, bytes, bytearray, subclassing of special descriptors, type layouts, float, generators, modules, argument passing corner cases, string literals and encodings, import and importlib, decimal, glob, the builtin module, json, math, operator, numeric tower, sys, warnings, random, f-strings, struct, itertools, super.

On top of that, the Python version was updated to 3.8.5. As it is becoming more well known in the community, the standalone version of graalpython can now be installed through pyenv.

LLVM bitcode runtime

Besides performance improvements and bug fixes, GraalVM 20.3.0 now supports code sharing in the GraalVM LLVM runtime. This allows the AST and compiled code of common bitcode libraries to be shared between multiple contexts within a single engine.

The LLVM toolchain was also updated to version 10.0.0.

Tools

A major improvement in tooling for GraalVM in 20.3.0 is the new VSCode GraalVM extension for Java. It includes a lot of functionality that simplifies working with Java projects. For example:

• Java syntax highlighting
• Java code completion
• Integrated Java debugger
• Integrated Polyglot debugger for GraalVM languages

There’s also a new VS Code Micronaut extension which leverages the features of the GraalVM extension for Java but also simplifies working with Micronaut apps, specifically helping to create new Micronaut projects and building native images of the Micronaut applications.

What do you want to see in GraalVM?

With every release we introduce new features that can make your applications run faster, open new opportunities and make the development process more efficient and fun. There are many things on our project roadmap, and we would love to hear from you which would be the most useful, and what is still missing. Respond to this survey to let us know how we should improve and extend GraalVM. Feel free to also share it with your team or community — having more opinions will help us to make GraalVM better for everyone.

Note that these are only some of the most notable improvements in the GraalVM 20.3.0! Please read a more detailed outline of the new and noteworthy features in the release notes. For the components you’re most interested in the changelogs are an invaluable source of information!

The downloads are available as always for GraalVM Community Edition 20.3.0 and GraalVM Enterprise Edition 20.3.0.

With all and any feedback please don’t hesitate to let us know on any of the channels: Slack, GitHub, or Twitter!

— GraalVM Team

GraalVM 20.3 is available was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

• small standalone distribution not requiring a JDK
• instant startup
• lower memory footprint

Native image is a very exciting way to deploy apps to cloud environments where these benefits determine the actual cost of running your applications.

However there is another class of applications that benefits from the above characteristics — command line apps!

Indeed, a good command line app is truly standalone, not like a docker run some-image standalone which involves downloading the infrastructure and the dependencies of the app just conveniently packaged. That was possible for ages: slap some @Grab annotations on the Groovy code, provide a wrapper to download the JDK, and call it a day. Native image gives you a binary that once you wget it is functional on its own.

A good CLI app starts fast! And if it doesn’t have a lot to do it dies fast too!

GraalVM Native Image precompiles your Java applications into native binaries, which don’t need to perform lots of boot-time initialization, like loading and verifying class files, and have startup times similar to apps written in other native compiled languages: Go, C/C++, etc.

Native executables also don’t need to initialize and allocate memory for the JIT compiler because there is no JIT compiler! Everything is compiled at build time. No JIT compiler means no code caches and no profile data caches which results in lower memory requirements than the same application running on the JVM. Your app will still consume memory for its own data of course, so if there’s a lot of data to process memory usage will grow as necessary but is still configurable with the normal -Xmx and friends command line options.

All in all, it checks a lot of the boxes for how a good CLI app should be. But in this article I want to explore one more cool feature of GraalVM native image — specifying the default memory requirements at the image build time.

Normally, for a Java application running on the JVM, you need to specify how much memory it can use at runtime. You run it with a command line like java -Xmx4G -jar myApp.jar and know that this application has its heap size limit at 4G. Without the -Xmx option the heap size will be determined by a heuristic, typically based on the total amount of memory available.

When you use GraalVM Native Image to compile your app, you can pre-set the heap size at build time. Let’s look at an example.

Let’s create a sample CLI application using Micronaut and Picocli and see how you can configure native executable memory.

You can go to launch.micronaut.io and create an app by specifying necessary components or use the command line utility mn. What’s interesting about mn is that it is itself a Micronaut command line app generated by GraalVM Native Image — a perfect example of a Java CLI application!

I’m using Micronaut 2.1.2:

mn create-cli-app primes; cd primes

We have the app ready, it’s a template for a CLI app that can respond to basic commands like --help. Let's create the business logic of a very important task of calculating prime numbers. CreatePrimesComputer.java in theprimes package using your favourite IDE:

It’s a very simple component, which can pick 2 random numbers up to the upperbound and return the list of prime numbers between them.

The calculation of the prime numbers is done using the Streams API, which is sort of inefficient but also not relevant for this exercise. This is actually remarkably convenient for the sample app since every calculation will generate a bit of data that is not used afterwards — i.e., garbage.

Let’s put it to use in the main PrimesCommand.java file:

It declares two integer options that our CLI utility will accept — how many iterations of the calculation to run and what’s the upper limit for the numbers to consider.

You can now try the app and see it work. For convenience — delete the test class left from the template (we could of course edit it to match our functionality, but removing is simpler):

rm src/test/java/primes/PrimesCommandTest.java.

Build the project now and run the resulting jar file:

./gradlew build 
...
java -jar build/libs/primes-0.1-all.jar
00:51:30.519 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [oraclecloud, cloud, cli]

You can see how quickly a Micronaut application starts! In less than a second!

We can also run it with some values for the arguments, so we see some output:

java -jar build/libs/primes-0.1-all.jar -n 1 -l 100 
[53, 59, 61, 67, 71, 73]

Remember, in the beginning of the article we said a CLI tool should start fast and use reasonably small amounts of memory. Let’s test the Java version just to have a baseline for those metrics:

/usr/bin/time -v java -jar build/libs/primes-0.1-all.jar -n 1 -l 100
16:34:02.776 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [oraclecloud, cloud, cli]
[53, 59, 61, 67, 71, 73]
    Command being timed: "java -jar build/libs/primes-0.1-all.jar -n 1 -l 100"
    User time (seconds): 2.73
    System time (seconds): 0.43
    Percent of CPU this job got: 309%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.02
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 354996
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 54451
    Voluntary context switches: 9774
    Involuntary context switches: 53
    Swaps: 0
    File system inputs: 0
    File system outputs: 64
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

I’m using the Linux time utility (or gtime on macOS) and in the verbose mode it shows a few interesting metrics:

• Max memory used by the app (max RSS): 355m
• Total wall clock time: 1.02s
• CPU usage: 309%

Note that the machine I’m testing this on is a decent cloud VM, with a few CPU and some RAM, which I often use as my remote developer machine.

This machine has quite a bit of memory available, which is perfect for development, but a bit detrimental to the heuristic based limit configuration: a good heuristic will see it has access to a ton of resources and decide to consume as much as convenient. That’s why we should not decide whether 350M consumed by a simple invocation of out utility is too much or not.

Remember these heuristics make a lot of sense for the server environment where your application is a sole consumer of the resources, even it it also makes CLI apps look more memory hungry than necessary. I’ll leave 300% of CPU and 1s to compute 5 prime numbers without a comment, it’s as good of a baseline as any.

Now a much better way to run this application is as a native executable generated by GraalVM Native Image. Fortunately, building a native executable of the Micronaut application is very straightforward as there’s a Gradle plugin that helps with the configuration and execution of the native-image utility.

Run ./gradlew nativeImage and after compiling and building the executable you'll have a standalone binary file ready for deployment.

The executable is available in the build/native-image/ folder, which we for convenience will move to the current dir: mv build/native-image/application ./primes-defaults

We can run it now and see that it works the same way as the Java version: ./primes-defaults -n 1 -l 100

And the same time command to check if the behaviour of the native image is a bit more appropriate for the CLI app:

/usr/bin/time -v ./primes-defaults -n 1 -l 100
23:57:47.286 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [oraclecloud, cloud, cli]
[53, 59, 61, 67, 71, 73]
 Command being timed: "./primes-defaults -n 1 -l 100"
 User time (seconds): 0.01
 System time (seconds): 0.01
 Percent of CPU this job got: 113%
 Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
 Average shared text size (kbytes): 0
 Average unshared data size (kbytes): 0
 Average stack size (kbytes): 0
 Average total size (kbytes): 0
 Maximum resident set size (kbytes): 49980
 Average resident set size (kbytes): 0
 Major (requiring I/O) page faults: 0
 Minor (reclaiming a frame) page faults: 1226
 Voluntary context switches: 232
 Involuntary context switches: 2
 Swaps: 0
 File system inputs: 0
 File system outputs: 0
 Socket messages sent: 0
 Socket messages received: 0
 Signals delivered: 0
 Page size (bytes): 4096
 Exit status: 0

Here are the highlights:

• 50M rss
• 20 ms total time
• 113% CPU

This is much-much better of course, but since we’re not configuring the memory limits, it’ll still use the heuristics and grow memory much more aggressively than you might expect if we increase the workload.

Luckily, we have the number of iterations to run in the parameters, so we can experiment very easily. Here’s an output of running 100K iterations of the same task:

Command being timed: "./primes-defaults -n 100000 -l 100"
    User time (seconds): 0.88
    System time (seconds): 0.63
    Percent of CPU this job got: 72%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.07
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 309956
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 65110
    Voluntary context switches: 199
    Involuntary context switches: 5
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

• 309M RSS
• 2s
• 72% CPU

(Just for completeness the Java JVM version shows me these results):

• 517M RSS
• 3.3s
• 171% CPU

Now if you still think 300M is more RAM than a good behaving CLI utility should take, you can control that with the -Xmx and -Xmn options at runtime, like this:

./primes-defaults -Xmx64m -Xmn16m -n 100000 -l 100

Or you can pre-build the default config values into the native image.

Add the following snippet to the build.gradle file:

nativeImage {   
  args("-R:MaxHeapSize=64m")   
  args("-R:MaxNewSize=16m") 
}

Here we specify the maximum heap size of 64m and the new generation size of 16m for the native image that will be built. These options will become the defaults for the native image executable. Build the native image again with ./gradlew nativeImage, to test it.

Move the binary too, so it won’t be overwritten by the future builds: mv build/native-image/application ./primes-limits

It still works the same:

./primes-limits -n 1 -l 100 
00:08:08.228 [main] INFO  i.m.context.env.DefaultEnvironment - Established active environments: [oraclecloud, cloud, cli] 
[53, 59, 61, 67, 71, 73]

But when we apply the load (the 100K iterations test), we can see the heap configuration in action the RSS doesn’t grow uncontrollably.

On my test machine I get:

• 60M RSS
• 2.02 total time
• 77% CPU

Also the native executable built this way will still respect the -Xmx, -Xmn config at runtime, so there's no downside like that for using the pre-baked limits you can increase them if needed.

Conclusion

GraalVM native image technology is great for command line applications. It produces a standalone binary that doesn’t depend on the JVM, starts instantly, doesn’t use a lot of memory, and lets you preconfigure reasonable heap configuration values for the workloads you expect by default. In this article we showed a sample command line application built with Micronaut and PicoCLI which is a terrific combination that works really well and is a good fit for native images.

There are a number of project that use GraalVM native image for the CLI apps:

• Native thin client for sbt
• Micronaut’s mn utility
• Google Closure compiler for JavaScript
• the Maven Daemon project

There are many many others. It’s probably a good fit for creating Kubernetes operators too, they are rather similar to the CLI apps, but perhaps that’s a topic for a followup article.

If you’re using GraalVM Native Image for command line applications, please tell us about it and how it works for you in the comments, or on Twitter, or Slack. We’re always looking to improve GraalVM further!

CLI applications with GraalVM Native Image was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today marks the release of GraalVM 20.2.0. This is a feature release and it packs a lot of improvements to performance, native image technology, and compatibility with the supported languages.

As always, we’re truly thankful to the amazing GraalVM community for collaboration, for providing feedback and raising issues, and for sending pull requests and talking about how you use GraalVM in your projects.

In this post we want to highlight some of the most notable changes in GraalVM 20.2.0. For a more detailed list please consider the release notes on the website.

Platform updates

In every release there are a number of fixes and improvements to every GraalVM component. The compiler is no exception. Let’s take a look at two new features you can try out in GraalVM 20.2.0:

In GraalVM Enterprise, the memory used by libgraal will now be released to the OS when an application enters a stable phase and compilation is idle. This is achieved by attaching each compiler thread to a libgraal isolate. The number of compiler threads that can be attached to an isolate is controlled by the jvmci.ThreadsPerNativeLibraryRuntime system property. The default is all threads attached to a single isolate. Isolates are initialized on demand to handle extra compiler threads. When a compiler thread becomes idle, which is configurable by the jvmci.CompilerIdleDelay system property, it detaches itself from its isolate. As the last thread detaches from an isolate, the isolate is shut down and its memory (i.e., the libgraal heap) is released to the OS. This feature has a number of advantages:

• It can reduce the RSS memory footprint of a GraalVM process. If the compiler is not being used, it uses no resources.
• If multiple isolates are used, it mitigates interference between complier threads. For example, there is less contention on shared objects, and a garbage collection in one isolate will not pause threads in other isolates.

Another notable addition to GraalVM Enterprise edition is a new, experimental, off-by-default partial loop unrolling optimization. Loop unrolling is a traditional compiler optimization that can improve performance for computational heavy, loop focused workloads.

Partial loop unrolling is an extended form of this optimization that works for counted loops with an unknown upper bound of loop iterations i. The transformation creates two versions of the loop: a main version of the loop that can be unrolled n times leading to an optimized loop body doing floor(i/n) iterations, and a fix-up loop doing the remaining number of i % n iterations.

Consider the following Java example:

for(int i = 0; i < upp; i++){
// body
}

Partial unrolling by a factor of 2 creates the two versions of the loop:

int i1=0;
int unrollFactor=2;
for(;i1<upp-unrollFactor;i1=i1+unrollFactor){
  // body i1
  // body i1 +1
}

int i2=i1;\
for(;i2<upp;i2++){
  // body
}

The major benefit of partial unrolling is the reduced number of jumps and updates to the loop control values, i.e., fewer counter increments and loop header jumps.

You can experiment with the new optimization by enabling it with -Dgraal.EnterprisePartialUnroll=true. However, note that it is experimental and thus may lead to unknown errors. We appreciate all feedback, so if you discover any issues during your experiments, please don’t hesitate to report them to the GraalVM team.

Native image

GraalVM Native Image continues to be a very exciting feature, and in 20.2.0 it got several important updates. Two of the features we’d like to highlight here are deployment improvements:

It was already possible to generate native executables where system libraries like libc are statically linked. This feature allows you to create fully standalone executables that can be used, for example, in the minimal FROM SCRATCH Docker containers that don’t have anything else present.

In 20.2.0, static compilation with Muslc got reworked and now you don’t have to rely on third party Muslc bundles. But it does require having a working musl-gcc in the system where you generate the native executable.

If you don’t have it installed and ready, there’s an instruction on how to get it.

You can verify that it is installed correctly by running:

musl-gcc -v

Then, generating a native executable statically linked against muslc is a matter of providing the following arguments to the Native Image utility:

 — static — libc=musl

Then the Docker image for the application deployment could look something like this, assuming `my-native-app` is the generated executable:

FROM scratch
COPY my-native-app /my-native-app
ENTRYPOINT [“/my-native-app”]

It’ll create an empty Docker image and only place your application into it.

Another interesting way of deploying native executables into containers is to use small Docker images with a minimum of dependencies, preferably with no operating system. For example, distroless images come to mind.

A distroless/base image contains only the following:

• ca-certificates
• A /etc/passwd entry for a root user
• A /tmp directory
• tzdata
• glibc
• libssl
• openssl

To build your native executable and statically link everything, except libc which is provided by the container, use the Native Image -H:+StaticExecutableWithDynamicLibC flag.

We also improved Native Image support for the G1-based garbage collector which is available in GraalVM Enterprise. If you would like to try a garbage collection implementation that lowers the GC pause times, specify your GC preference with the following option: -H:+UseLowLatencyGC at build time. The native executable will build normally, and at runtime you can configure its memory usage with the usual flags -Xmx and monitor the GC activity with the -XX:+PrintGC or -XX:+VerboseGC.

Last, but not least, there’s a potentially breaking change in 20.2.0: the class initialization strategy has been changed to include fewer classes from the JDK library to be initialized at build time.

If you are initializing your application classes at build time, they might trigger initialization of the JDK library classes at build time, which will conflict with the new strategy, and the build will not succeed. You can solve this problem by introducing the build time class initialization for necessary classes, yourself.

For example, for a sample Micronaut application, I needed to add — initialize-at-build-time=com.sun.org.apache.xerces,com.sun.xml.internal,jdk.xml.internal to the command line to initialize those classes at build time, like prior to the 20.2.0 release.

If you’re relying on a framework or library to configure your native image generation, you might need to update it to a more recent version that works with the 20.2.0.

Truffle

One important change to the Truffle language implementation framework was changing the default inlining heuristic for the language interpreters in which inlining budgets are based on Graal IR node counts and not Truffle Node counts.
This is a very interesting change that makes inlining, which is a very important optimization, work better at estimating the cost of the optimization. A Truffle node can be of arbitrary complexity and overspend the inlining budget by “tricking” the inlining heuristic into counting it as just one node. So estimating code size for inlining based on the Truffle node count could lead to inefficient results.

A very welcome addition to the language implementation API available in 20.2.0 is the DynamicObject model, and library to make use of it. You can find more details in the docs, but in a nutshell — they allow language implementations better control over the layout of objects in dynamic languages, and accommodate dynamically adding members or changing types. This allows better handling of objects by shapes and makes accessing object properties more efficient.

JavaScript

In GraalVM 20.2.0 we updated Node.js to version 12.18.0. We also implemented a number of proposals: Intl.NumberFormat Unified API, the Logical Assignment Operators, the Top-level Await proposal, even the Promise.any proposal (available with the ECMAScript 2021 mode).

There’s also a freshly implemented support for async stack traces that you can try.

Ruby

We’d like to highlight the compatibility improvements in TruffleRuby in GraalVM 20.2.0. Besides a ton of other changes you can see in the release notes, now the Ripper stdlib has been implemented using the C extension.

This release has also improved compatibility (notably refinements) and updated to Ruby 2.6.6, added better interoperability support with other languages, and includes various performance improvements.

Python

Among the most notable changes in GraalPython, we implemented better reference counting for native extensions to fix memory leaks.

We also introduced code serialization to .pyc files (.pyc files persistently store the Python bytecode compiled from the source .py files), which should improve startup of Python programs.

GraalVM Enterprise Python implementation now also includes a faster implementation of _struct.

Tools

Tools are a very important part of the GraalVM project. In 20.2.0 there was a number of improvements to GraalVM support in VSCode.

The Language Server Protocol implementation now supports latest protocol version 3.15. GraalVM LSP is a very interesting addition to the usual LSP implementation in VS Code — it can notice dynamic information only available at the runtime of your program and use that to add suggestions to the content assist in the IDE for you.

All GraalVM VSCode extensions were merged into one, which you can obtain from the marketplace.

VSCode can also now show code coverage from GraalVM LSP.

VisualVM now includes a GoToSource action, so you can jump from the profiler into your preferred IDE. This is a welcome addition to quickly navigate to the place in your code that requires the most attention.

If you configure it with the source roots location:

And right click on the class or method name in one of the views, for example in the CPU profiler:

It opens that file in your favourite IDE:

These are only some of the improvements we are so proud of in the GraalVM 20.2.0 feature release! Please read a more detailed outline of the new and noteworthy features in the release notes and consider looking at the changelog for the project components on GitHub!

Download GraalVM 20.2 or GraalVM Enterprise 20.2, use it for running your applications, and build new, exciting projects. If you have any feedback please don’t hesitate to let us know on Twitter, Slack or GitHub!

— GraalVM Team

Announcing GraalVM 20.2.0 was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.