Native Image Committer Community Meeting 2021-09-20

[christianwimmer]

List of all past and upcoming meetings: #3933

New and Noteworthy

• JDK 8 support is going to be deleted. After the 21.3 release, we will gradually remove all testing on JDK 8 and then delete all the JDK 8 specific code before the 22.0 release. No PR yet though.

• Configuration file entries that are necessary at image build time for reflection, JNI, resources, and Proxy, can now be conditional based on the reachability of class. This allows a more precise configuration, which can reduce the size of a native image. Documentation with more details and an example for a conditional reflection configuration.
  [GR-32340] Predicated configuration for Native Image. #3606
  [GR-32340] Conditional resource configuration. #3774
  [GR-32340] Introduce default resource-registration methods. #3803

• A native image now always contains reflection metadata for all methods that were seen as reachable by the static analysis. Calling Class.getDeclaredMethods (and all the other variants to look up methods and constructors) now returns all reachable methods for all classes. Previously, only methods that were explicitly registered for reflective invocation were returned. This new feature allows significant reduction of the manual reflection configuration: only methods that need to be invoked via Method.invoke, or methods that would not be seen as reachable based on reachability, need to be registered manually.
  [GR-21937] Distinguish between invoked and queried reflection methods #3637

• Added several new optimizations to reduce the image size as well as the image build time for large applications.
  [GR-33636] Do not use a separate class for each reflectively invoked method. #3765
  [GR-33636] Fix and improve Graal IR for reflection. #3777
  [GR-31510] [GR-32349] Improve image build time. #3529
  [GR-33665] Optimize serial GC write barrier for non-array stores. #3771
  [GR-14813] Remove unnecessary class initializations. #3595
  [GR-32057] Propagate assignable types eagerly. #3641

• Initial support for the Java Platform Module System: The native image generator now accepts the module-related arguments known from the java launcher like -m, -p, and --add-opens. When such a module-related argument is used, then the image generator itself is used as a module too. There were many PRs for this over the last months. Here are just a few of them:
  [GR-33549] Run image-builder on modulepath when module options are used. #3763
  [GR-33359] Fix image name argument parsing when combined with -m option #3622
  [GR-30957] Implement Module/ModuleLayer substitutions #3445
  cf56a33
  [GR-32505] Make NativeImageClassLoaderSupport#initAllClasses take jdk.module.upgrade.path into account. #3552
  [GR-31840] [GR-31681] Allow native-image shared libs to be built on module-path and fix resource bundle lookup. #3446
  [GR-30433] Make native-image driver buildable via --module-path. #3382

• Added a new policy for the Serial GC reducing the memory footprint of applications at run time. The new policy enables survivor spaces for the young generation. In addition, a full GC no longer scans the whole image heap for root pointers, but only parts of the image heap that have been written to.
  Adaptive GC policy and other improvements. #3589
  f3c2685

• Small methods are now inlined before the static analysis to improve the precision of the static analysis.
  ab9bfcf
  [GR-28460] Improve InlineBeforeAnalysis. #3640
  [GR-28460] Enable method inlining before static analysis by default. #3628
  [GR-28460] Remove old version of inlining before analysis. #3545

• Arguments to the native image generator can now be passed in a separate file that is provided with the @argument option. This is a necessary workaround for platforms like Windows where the the length of the command line is limited.
  Use @argFiles to prevent issues with long command line invocations #3734

• Root certificates can now be configured at image run time. Documentation with details and a list of system properties that are now read at run time to configure the root certificates.
  [GR-32212] Add support for runtime configuration of default trusted KeyStore. #3652
  Load root certificates at image build time #1999

• Crash dumps, which are printed when a segfault or a fatal VM error happen, now include more details to aid diagnostics.
  [GR-30765] Extend Native Image diagnostic output. #3515
  [GR-33334] Better control over diagnostic thunks. #3795
  [GR-33334] Fix endless loop in error handling. #3741

• The beginning of the image heap is now protected memory so that null pointer accesses produce a segfault instead of accessing random memory.
  e412034

• Internal VM errors, where an illegal virtual method table entry is accessed, produce a better crash dump.
  [GR-33229] Fill unused vtable slots with a stub that reports a fatal error. #3702

• On Linux, the processor count reported at run time now takes limitations set via cpuset into account.
  [GR-26994] Add support for cpusets on Linux. #3762

• Improved Dwarf debug info generation now includes information about inlined methods.
  [GR-33516] Updated fix for inline debuginfo to fix issue 2701 #3745

• JDK Flight Recorder (JFR) support is now also available for JDK 17.
  Update JFR Native Image Support for compatibility with JDK 17 #3726

Deep Dive: Improvements in the static analysis

Parse bytecode only once

Historically, the bytecode of all methods was parsed twice during an image build: for static analysis, and then again for AOT compilation. That had advantages for images with Truffle languages that need deoptimization and JIT compilation (and is done that way for such images today). But over time, we ran into more and more subtle problems: the two parsings can get out of sync. Then code that the static analysis did not see as reachable suddenly got AOT compiled, leading to strange errors at run time.

aa2f6e8 is the switch to "parse once".

• Static analysis results are now applied to the Graal graphs that were parsed for analysis: StrengthenGraphs
• Graal graphs are "transplanted" from the "analysis universe" into the "hosted universe": CompileQueue.transplantGraph

Inline methods before static analysis

One of the main reasons for "parse once" was to allow method inlining before static analysis. We experimented with inlining before analysis beforehand, but the first implementation (before "parse once") was not reliable and is now removed (#3545).
The new inlining before analysis is a multi-step process:

• All graphs are parsed without method inlining first: AnalysisParsedGraph
• The parsed graph is immediately encoded into a more compact representation, also used by the Truffle partial evaluator.
• When the MethodTypeFlowBuilder processes a method that is reachable, the encoded graph is decoded again, and method inlining is done during decoding: InlineBeforeAnalysis

The policy for inlining before analysis is quite conservative: InlineBeforeAnalysisPolicyImpl only inlines methods with one computational Graal node. This can be a method invocation (so "forwarding" method calls are inlined), a field access, arithmetic, ... Constants do not count to the limit. We can never reduce inlining because that would be a backward-incompatible change!

Note that only methods that can be statically bound without any static analysis or speculation can be inlined before the static analysis. So this is limited to static methods, or final / private instance methods. But it is enough for some important use cases in Spring where reflective method lookups needs to be constant folded: #2500 (comment)

Image heap scanning

Currently, the static analysis scans the image heap repeatedly: PointsToAnalysis.finish. This is time consuming for no good reason (other than "we have always done it that way"). Image heap writing after static analysis then scans all objects again: NativeImageHeap.addObjectToImageHeap. This can lead to inconsistencies and hard-to-debug error messages.

We are in the process of changing this, and visit each object only once during static analysis to build a "shadow heap". Some pre-work for this is already merged, like #3641,

Open Discussion

Possible deep dive topics for next meeting

Please send suggestions, or "upvote" a suggestion, by adding a comment to this discussion.

• Reflection data for all methods
• Conditional reflection configuration
• GC policy and GC performance
• Class initialization at image build time vs. run time
• Incomplete class paths and the future of --allow-incomplete-classpath (there is some discussion about that in Remove some limitations of GraalVM Native Image #2762)

[ziyilin]

The topics are very interesting. I'd vote for the "GC" topic for the next meeting.
When I read the source code, I may get lost in the details. Introducing some of the big pictures such as the reasons behind the design would be very helpful.

[christianwimmer]

The next meeting will be on Thursday, October 21, at 17:00 Central Europe / 11:00 Eastern / 8:00 Pacific Time

[galderz]

Incomplete class paths and the future of --allow-incomplete-classpath (there is some discussion about that in Remove some limitations of GraalVM Native Image #2762)

^ I've just created #3929 with ideas to improve the usability of this configuration option.