Native Image Committer and Community Meeting 2025-02-27

[wirthi]

List of all past and upcoming meetings: #3933

The meeting after this one is planned for March 27th, 2025. The meeting will typically be on the last Thursday of each month.

New and Noteworthy

• JDK 24 is feature complete, continuing to update to latest JDK 25 versions
  [GR-62457] Update labsjdk to 25+11-jvmci-b01 #10731
  [GR-62014] Avoid symbol versioning issues in shim libraries. #10649

• Native Image Layers
  [GR-61285] Relink static final fields across layers #10729
  [GR-60876] Load all instantiated types in application layer #10661
  [GR-62314] Register libraries from base layer in extension layers #10764
  [GR-62290] Fix concurrency issue with base layer graphs #10700
  [GR-59403] Don't require all virtual roots to be installed in vtables. #10689
  [GR-61460] Reload PolymorphicSignature methods #10686
  [GR-61928] Add BaseLayerMethod.isBridge. #10668
  [GR-59855] Make StaticFinalFieldFoldingFeature layer aware #10654
  [GR-61421] Allow InitialLayerOnlyImageSingletons to be folded within future layers. #10642
  [GR-61427] Set implementations of methods as reachableInCurrentLayer too #10559

• GuestGraal / LibGraal

• Streamline reachability metadata

• Usability
  [GR-62119] Remove AccessAdvisor assertions with data races. #10683 (agent fix)
  [GR-61524] Log configuration entries filtered by the NI agent. #10641 (agent)
  [GR-61498] Filter java.lang.System$LoggerFinder when tracing resource accesses. #10597 (agent)

• Monitoring / tools

• Debugging
  [GR-61595] [GR-62153] [GR-62324] Small fixes and add more information to crash log output. #10734
  [GR-44775] Fix -H:-StripDebugInfo. #10688
  [GR-61492] Add native-image JDWP to the standard GraalVM. #10631 (experimental and off by default)

• FFM API / Panama
  [GR-61751] Use different scratch registers in MacroAssembler for SubstrateVM #10715

• Remove JDK 21 from our master branch
  [GR-62335] Remove all JDK 21 compiler suite CI jobs. #10707

• SBOM generation
  [GR-62099] Update documentation for SBOMs generated with Maven #10684

• Other
  [GR-55222] Support Lazy Deoptimization #10639
  [GR-62080] Prevent out-of-memory errors during deoptimization #10741 (enabled by Lazy Deoptimization)
  Add nativeimage-libgraal to module path for non-jlinked JDKs #10710 (Red Hat)
  [GR-54786] Cross-isolate exception dispatch for isolated compilation. #10617

• fixes
  [GR-61590] [GR-61408] [GR-60880] Add support for handling unsigned comparisons in points-to analysis. #10628
  [GR-61888] Fix @Uninterruptible. #10621
  [GR-60649] [GR-61423] Various fixes for system properties and locales. #10613
  [GR-45784] [GR-61420] [GR-61901] Various smaller fixes and cleanups. #10635
  [GR-62036] Add missing HOSTED_ONLY annotations to CGlobalData. #10659
  [GR-61494] [GR-60855] Analysis Refactoring & Minor Improvements #10660
  [GR-44352] [GR-61906] Mark ZoneOffset.rules with RecomputeFieldValue #10663
  [GR-44775] Fix incorrect calculation of "other data". #10680
  [GR-45784] [GR-61965] Reenable all checks regarding @Uninterruptible and other minor changes. #10703
  [GR-61998] Prevent walking image heap continuations with unpatched references and carrier threads unexpectedly leaking into frames. #10712
  [GR-46400] Ensure resources are registered with proper names for run-time lookup #10725
  [GR-62340] Use correct acquisition count in acquireOnOOME. #10722
  [GR-61534] Ensure static word fields are not unsafe accessed. #10676

Questions

Deep Dive: Foreign Function and Memory API (JEP 442, Panama) outlook for JDK 25

Introduction

The Foreign Function and Memory (FFM) API (aka. Project Panama) enables Java programs to interoperate with native code.
This API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.

See also: JEP 454

The FFM API is contained in the package java.lang.foreign.

There is an ongoing effort in the JDK to panamize (i.e. replacing JNI with FFM API usage) everything.
E.g. SunLayoutEngine

Current Status of FFM API Support in Native Image

Tracking issue: #8113

• Most features of the FFM API are already supported (since GraalVM for JDK 22 -> GraalVM 24.0.0)
  • We run and pass most of JDK's FFM API tests
  • Some tests are not suiteable (e.g., they are whitebox tests, trigger deopt, ...)
• Support is still experimental
• Full support for the FFM API is ongoing work
• Main challenge: dynamic nature of the API (method handles, varargs, ...)

Missing Features / Open Tasks

• Shared arenas (i.e. Arena.ofShared())
• Improve downcall performance (currently always unoptimized)
• Improve upcall performance (currently always unoptimized)
• Improve MemorySegment performance (currently always unoptimized)
• Platform support
  • missing for AArch64 (any OS)
  • missing for Windows AMD64

How to Use FFM API on Native Image (Demo)

• Enable with option -H:+ForeignAPISupport
• Provide information (signatures, linker options) about upcalls (native code calls Java method) and downcalls (Java method calls native function)
  • Provide a configuration file (-H:ForeignConfigurationFiles=)

    "downcalls": [
      # primitives
      { "descriptor": "(byte, short, long, int, double, float, jboolean, jbyte, jshort) void" },
      # array parameter
      { "descriptor": "([8:char]) void" },
      # struct with padding
      { "descriptor": "({jshort, X2, jint}) void" },
      # struct with custom alignment
      { "descriptor": "({jshort, 2%jint}) void" },
      # union
      { "descriptor": "(<int, double>) void" },
    ]
    

  • Use RuntimeForeignAccess in a user-provided feature

Outlook GraalVM for JDK 25.0.0

• Shared arenas (i.e. Arena.ofShared())
• Platforms Windows AMD64 and Linux/MacOS AArch64
• Improve downcall performance
  • Only possible for constant downcall handles
  • Aims for jextract generated patterns
  • Automatically detect signatures (similar to reflection)
  • Provide hints if optimization failed and why
• Improve upcall performance ([GR-52576] Introduce specialized upcalls for direct method handles. #10235)
  • Only possible for direct method handles
  • Specify in configuration file (or feature)

    "directUpcalls": [
      { "class": "my.package.MyClass", "method":  "aStaticMethod", "descriptor":  "() void"},
    ]
    

• More user-friendly but still expressive configuration syntax
  • A syntax based on how layout objects are constructed in Java
  • Similar to jextract output
  • Example:

    sequence(5, struct(jshort, padding(2), jint))
    

    in Java:

    MemoryLayout.sequenceLayout(5, MemoryLayout.structLayout(ValueLayout.JAVA_SHORT, MemoryLayout.paddingLayout(2), ValueLayout.JAVA_INT))
    

• Native Image Agent support
• Make -H:+ForeignAPISupport the default

Resources

• Reference Manual
• RuntimeForeignAccess

[sgammon]

@wirthi I'm not a committer, but is there a way to provide some early feedback on Native Image layers? We have already managed to use them and some builds are passing, but there are some questions about use case once they land (particularly in terms of cross-layer use of Truffle)

[wirthi]

Sure, you can either do it here on GitHub (as discussion or issue) or maybe even preferred (for easier discussion) on the GraalVM Slack workspace (truffle or native-image channels, whatever fits your question better).

We also plan to have a Deep Dive on Layers in our call in March.