Native Image Committer and Community Meeting 2023-04-06

[christianwimmer]

List of all past and upcoming meetings: #3933

New and Noteworthy

• GraalVM 23.0: Last chance for fixing blocker bug this week.

• We are (finally) removing the no longer necessary JDK 11 specific substitutions:
  [GR-45327] Remove JDK 11 support from native image code. #6343
  [GR-45327] Remove JDK 11 support from native image code. #6355

• Support for JDK 21 is coming:
  [GR-44862] [GR-44252] JDK 21 adoption. #6337

• Bundles: The implementation is "good enough" so we dropped the --enable-experimental-bundle-support option. It is still considered experimental though.
  [GR-45130] Replace --enable-experimental-bundle-support with a warning. #6297
  [GR-44387] Add documentation for bundle options. #6315
  [GR-44870] Ensure bundle temp directory gets deleted in case of SIGTERM. #6243
  [GR-44820] Fix bundle support for --diagnostics-mode. #6208
  [GR-44872] Normalize env-var keys to upperCase on Windows. #6214

• Reflection / resources / serialization registration:
  [GR-42112] Missing registration errors for reflection calls #6139
  [GR-44834] Proofs for reflection queries #6296
  [GR-45009] Fix missing reflection registration tests #6305
  [GR-44749] Simplify missing reflection registration options #6288
  [GR-44291] Automatically register resources when the class and the pattern are constant. #6177
  [GR-43872] Serialization bugfixes. #6222

• Product renaming:
  [GR-44722] Adjust version strings and properties in Native Image. #6302
  [GR-44722] Make vendor version adjustable at build-time. #6356

• Compatibility:
  [GR-44675] [GR-44081] Support ScopedValue and use Blocker in Object.wait if pinned. #6247
  [GR-39848] Do not use method and field annotations during JIT compilation. #6362 One step closer towards never looking at all annotations of a type/method/field

• Other
  [GR-45112] Ensure @RawStructure fields have getters and setters. #6310
  [GR-35746] Decrease aligned chunk size to 512 KB. #6115

• Monitoring / tools:
  Crash dump improvements: [GR-33548] Improve Native Image diagnostics. #6341
  [GR-45014] [GR-45015] Support JFR and heap dumping on Windows. #6375

• Not related to Native Image, but still worth mentioning: ZGC now supported for Graal JIT compilation.
  [GR-27475] Add ZGC support #6170
  For ZGZ, barriers are part of LIR code generation, not lowered using Graal IR. We plan to switch this model for all other GCs too.

Deep Dive: Uninterruptible

In "normal Java code", every method exit and every loop backedge is a potential safepoint. But every VM has low-level code that must be safepoint free. Since Substrate VM is written in Java, we do this via an annotation on Java methods: @Uninterruptible.

(HotSpot VM: C++ code has explicit safepoint checks, and so code without an explicit check is uninterruptible. The Maxine VM has an explicit thread state with a different set of VM-thread-locals)

Several things are tied to Uninterruptible for convenience:

• Safepoint checks
• Stack overflow checks (frequent pattern: enable yellow zone in uninterruptible code, then switch to interruptible code)
• Recurring callbacks (because they are implemented as part of safepoint checks).
• Must not allocate (because that could require GC) or synchronize
• Implicit exceptions throw a pre-allocated singleton (but throwing exceptions itself is allowed for pragmatic reasons)

When calling C code from uninterruptible Java code, you must use NO_TRANSITION.

Entering / exiting uninterruptible code is "free", i.e., no machine code, thread state transition. You cannot query the uninterruptable state (and you do not need to because every method is annotated anyways).

Uninterruptible "spreads like a cancer" because many methods are annotated as @Uninterruptible(reason = "Called from uninterruptible code.", mayBeInlined = true). We tightened the rules a bit recently in #6124 but the fundamental problem remains and is not solvable.

@Uninterruptible affects inlining:

• Uninterruptible code is only inlined into interruptible code if @Uninterruptible(mayBeInlined = true) is used. When inlined into an interruptible caller, the code loses the properties that are usually guaranteed by @Uninterruptible.
• Uninterruptible code may always inline other uninterruptible code, regardless of mayBeInlined = true.

Code that runs inside a VMOperation does not need to be uninterruptible, even though the safepoint check cannot trigger (since the VM is already at a safepoint).
Draft PR to make the GC uninterruptible: #6374

All code that runs before attaching a thread to the VM / after detaching a thread from the VM / in a thread not attached to the VM must be uninterruptible. And such code must even obey stricter rules, like no Java heap access.
So one idea for making a parallel GC like #6349 is to have GC threads not attached, and only executing uninterruptible code.

Possible deep dive topics for next meeting

• Simulation of class initializer at image build time, to allow the new class initialization strategy where all classes can be used at image build time.

Please send suggestions in the GraalVM Slack channel