Native Image Committer and Community Meeting 2026-01-29

[wirthi]

List of all past and upcoming meetings: #3933

The meeting after this one is planned for February 26th, 2026. The meeting will typically be on the last Thursday of each month.

New and Noteworthy

• Native Image Layers and Analysis improvements
  [GR-70850] Make ImageInfo layer aware #12848
  [GR-72054] [GR-71348] Improve reflection registration in extension layers #12842
  [GR-71903] Singleton traits refactor #12839
  [GR-64070] Make sure VarForm.memberName_table is initialized #12787
  [GR-72207] Eagerly initialize CalendarSystem #12785
  [GR-71745] More standalone analysis cleanup for Terminus #12735

• Crema
  [GR-70676] NI-based libjvm shared library. #12689
  [GR-72784] Implement jdk.internal.misc.VM#getRuntimeArguments for native-image. #12869
  [GR-72019] [GR-72418] Improve NI-based libjvm shared library. #12835
  [GR-72470] Crema: Add a better error message for issues with unmaterialized field #12788
  [GR-71554] Ristretto: run with explicit exception mode until deopt support is done. #12754
  [GR-71852] Ristretto: support call lowering. #12789

• Project Terminus: Self-hosting Native Image #12236 (Towards the "Hello, Espresso World!")
  [GR-72100] Add GraalAccess.getVMAccess #12739
  [GR-71842] Introduce the org.graalvm.nativeimage.guest module #12818
  [GR-72501] Added VMAccess.owns API #12816
  [GR-72115] Move JVMCIReflectionUtilFallback implementations to VMAccess #12846
  [GR-72090] Support calls from JIT code to dynamically loaded static methods #12872
  [GR-72093] ImageHeapScanner hashCode precomputation refactoring #12864
  [GR-72890] Implemented getEnclosingType, isLocal and isMember for EspressoExternalResolvedInstanceType #12857
  [GR-72002] Make it possible to use espresso's VMAccess in native-image #12855
  [GR-72691] Make it possible to use espresso early in the native image generator #12850
  [GR-72661] [GR-72689] Make it possible to use truffle early in the native image generator #12845
  [GR-72097] Remove jdk.graal.compiler.word.Word #12822
  [GR-72441] Added VMAccess.asResolvedJava{Field,Method} #12810
  [GR-72536] Migrate further FieldValueTransformerWithAvailability implementations #12800
  [GR-72015] Migrate various FieldValueTransformers to JVMCI #12792
  [GR-72026] Implement EspressoExternalResolvedJavaMethod.hasAnnotations #12784

• Streamline reachability metadata
  [GR-72447] Make 25 the minimum java version for metadata tests. #12776

Note: include the metadata schema PR in downstream distributions.

• Usability
  [GR-72134] Print fully qualified names for security providers in error messages. #12746

• Monitoring / Tooling / Debugging
  [GR-72496] Improve error reporting in TestJfrStreamingCount. #12851
  [GR-72637] Improve heap dump error reporting. #12820
  [GR-72468] Only set JavaMonitor.latestJfrTid if JFR support is enabled. #12791

• Garbage Collector / Memory Management
  [GR-72023] Allocation and write barrier refactorings. #12803
  [GR-72423] Overwrite GC sizes if option value changes at run-time. #12779
  [GR-71654] [GR-72101] [GR-72102] Remove the Java heap allocation in AbstractCollectionPolicy.updateSizeParameters() + fixes and optimizations. #12752

• Shenandoah GC: ongoing effort by Amazon

• Other & fixes
  [GR-42804] Disallow System.err and printStackTrace(). #12854 (!)
  [GR-71607] Deprecate and delete FallbackFeature. #12755 (!)
  [GR-71155] Implement ImageHeapObjectSortFeature #12863
  [GR-72024] Improve recurring callback performance. #12860
  [GR-72762] Improve isolate thread verification. #12840
  [GR-72513] Do not @Fold runtime-only singleton RawFileOperationSupport values at image build-time. #12838
  [GR-45790] [GR-72531] [GR-72532] Optimize runtime option access and make runtime option values accessible from uninterruptible code. #12837
  [GR-72588] Catch proper exceptions in VarHandleFeature#eagerlyInitializeVarForm #12831
  [GR-72037] Print Histogram to file instead of console. #12829
  [GR-72512] Speed up native-image --version, --help, and --help-extra. #12814 (blog post measured performance of native-image --version)
  [GR-49707] Avoid suffix duplication in the generated image name. #12799 (no more lib.so.so or myapp.exe.exe)

Questions

@wirthi we intend to stop publishing (for future releases) https://mvnrepository.com/artifact/org.graalvm.nativeimage/svm (which is implementation details), everything relevant for your usecases should be (or needs to be) in in the public API https://mvnrepository.com/artifact/org.graalvm.sdk/nativeimage - who is still depending on the internals? Is anything missing in the API that is blocking you from moving? See #12738

Deep Dive: @olpaw on AOT-compiled Crema-based Java launcher

From "JDWP Support for NI" to "Crema-based LIBJVM"

To improve our NI debugging experience we implemented JDWP Support for NI

Supporting JDWP protocol needs a bytecode interpreter. Taking the core interpreter part of Espresso was the obvious choice.

Project Crema (reuse the bytecode interpreter to allow runtime-classloading in NI)

Certain features of the JDK are implemented by generating bytecodes at runtime (Proxy classes, XSLT, method handles, serialization, ...). To fully support those aspects of the JDK we need runtime-classloading.

Espresso vs. Crema

Espresso provides an isolated JVM implementation on top of a VM runtime. Crema on the other hand allows dynamically loaded code to link with classes/fields/methods of the underlying VM. The delegation-based class loader hierarchy allows Crema to resolve against AOT compiled classes.

what if? 🦖

Native image allows us to

• create shared library images
• and supports JNI, including JNI_CreateJavaVM

This is exactly what is used by the java launcher to instantiate the JVM. Now with Crema we can build our own libjvm.so that should be able to load classes like regular Java does.

The java launcher passes the command line args to the JVM as system properties. As _JAVA_LAUNCHER_DEBUG=true reveals

...
Java args:
Command line args:
argv[0] = bin/java
argv[1] = -svm
argv[2] = -cp
argv[3] = /home/pwoegere/OLabs/hello
argv[4] = HelloJava
...
JavaVM args:
...
    option[ 1] = '-Djava.class.path=/home/pwoegere/OLabs/hello'
    option[ 2] = '-Dsun.java.command=HelloJava'
    option[ 3] = '-Dsun.java.launcher=SUN_STANDARD'

The VM instance knows about the classpath from system property java.class.path.
If we configure NI to initialize jdk.internal.loader.ClassLoaders at runtime it should be able to pick up the classpath specified by the user.

And indeed it does (with #12689):

----_JAVA_LAUNCHER_DEBUG----
...
15 micro seconds to parse jvm.cfg
Does `/home/.../lib/svm/libjvm.so' exist ... yes.
mustsetenv: FALSE
JVM path is /home/.../lib/svm/libjvm.so
5105 micro seconds to LoadJavaVM
JavaVM args:
    version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 4
    option[ 0] = '-Dsun.java.launcher.diag=true'
    option[ 1] = '-Djava.class.path=/home/pwoegere/OLabs/hello'
    option[ 2] = '-Dsun.java.command=HelloJava'
    option[ 3] = '-Dsun.java.launcher=SUN_STANDARD'
4354 micro seconds to InitializeJVM
Main class is 'HelloJava'
App's argc is 0
11955 micro seconds to load main class
----_JAVA_LAUNCHER_DEBUG----
Hello 𝓙𝓪𝓿𝓪 ☕

From java -cp hello HelloWorld to java HelloWorld.java

Since https://openjdk.org/jeps/330 Java can load simple programs without requiring the user to use javac first. In our Crema-based libjvm we can make this real fast. By making sure the classes used by the java launcher for this mode of operation are already in the image and accessible via JNI. Adding a bit of additional configuration (and a bit more, see #12835)

{
  "type": "com.sun.tools.javac.launcher.SourceLauncher",
  "jniAccessible": true,
  "methods": [
    {
      "name": "main",
      "parameterTypes": [
        "java.lang.String[]"
      ]
    }
  ]
}

we come to a point where we can start comparing against regular Java:

Try it out for yourself:

cd graal/substratevm
mx build
mx native-image --macro:jvm-library
cd $(mx graalvm-home)
bin/java -svm HelloWorld.java

Planned next steps

• Ristretto (JIT compilation for Crema)
• Support more than just variations of "Hello World"
• Ensure dynamically loaded classes are accessible via JNI (currently a hack).
• More user-friendly configuration of what should already be AOT-compiled in the image

[olpaw]

To follow up on @simonis question, by making jdk.internal.loader.ClassLoaders, initialize-at-run-time, its static initializer at image-runtime executes https://github.com/openjdk/jdk/blob/847b5166ea6322f9ff3effa62ed6d1e73a8b1122/src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java#L94

URLClassPath ucp = new URLClassPath(cp, false);
if (archivedClassLoaders != null) {
    APP_LOADER = (AppClassLoader) archivedClassLoaders.appLoader();
    setArchivedServicesCatalog(APP_LOADER);
    APP_LOADER.setClassPath(ucp);
} else { /* unreachable */ }

and this is how the NI built-in APP_LOADER instance actualizes its classpath with what is coming from the java-launcher.