Native Image Committer Community Meeting 2021-10-20

[christianwimmer]

List of all past and upcoming meetings: #3933

New and Noteworthy

• GraalVM 21.3 is released. Needed more last-minute bugfixes than we hoped.

• Please benchmark the new GC policy and provide feedback. Ideally with the latest daily snapshot build. Or with the 21.3 release and option -H:InitialCollectionPolicy=Adaptive.

• JDK 8 support is going to be deleted. Several PRs already switch some testing from JDK 8 to JDK 17 and do some cleanups:
  Switch SVM gates from JDK 8 to JDK 17: beda3cc
  [GR-34577] Remove support for outdated JDK versions between 11 and 17. #3924

• Module system support:
  [GR-34108] Extend boot module layer to include required modules #3821
  [GR-31710] Support building js-launcher with image-builder on module-path. WIP #3748

• Robustness:
  Fail when invoking invalid method pointers #3874
  [GR-33915] Add verification for invoke receiver types. #3830

• Compatibility improvements:
  [GR-30807] Use a dedicated reference handler thread by default. #3925
  Proper getStackAccessControlContext implementation #3854
  [GR-34403] Add missing exception edge for array allocations. #3883
  Support for lambda class serialization #3792
  [GR-8209] Introduce an option to change the default charset. #3834

• JFR support:
  Add JFR support for threads: Improving JFR support #3720
  Add JFR events for the garbage collector #3743

• Image size reduction:
  [GR-32403] Compress FrameInfo Encoding. #3928 (not ready for review or merging)

• Static analysis:
  Refactor Native Image heap scanning. #3926 (not ready for review or merging)
  [GR-31713] Implement a prototype of Reachability Analysis for Native Image #3801 (not ready for review or merging)
  Parse pointsto options for standalone pointsto #3666
  Refactor iterative analysis code to common method #3773

• Medium-term planning:
  Continuations/coroutines (support for Project Loom). Initial support was merged a year ago, but several bigger pieces and optimizations are still missing.

Deep Dive: Class initialization at image build time vs. run time / complete vs. incomplete classpath

Class initialization

• Default is initialization of classes at run time
• Options --initialize-at-build-time and --initialize-at-run-time work at the level of package names and class names:

  graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/classinitialization/ClassInitializationFeature.java

  Line 83 in 64389bc

  ClassInitializationOptions.ClassInitialization.getValue().getValuesWithOrigins().forEach(entry -> {

• The core of the JDK is initialized at image build time, with a curated list of exceptions:

  graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/jdk/JDKInitializationFeature.java

  Line 35 in 1477a82

  public class JDKInitializationFeature implements Feature {

• A simple bytecode-level-analysis before the static analysis initializes some simple side-effect-free classes early:

  graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/classinitialization/EarlyClassInitializerAnalysis.java

  Line 114 in 320fe54

  boolean canInitializeWithoutSideEffects(Class<?> clazz, Set<Class<?>> existingAnalyzedClasses) {

• A inter-procedural analysis that uses static analysis results initializes some more complicated side-effect-free classes before compilation:

  graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/classinitialization/TypeInitializerGraph.java

  Line 66 in 153141d

  public class TypeInitializerGraph {

Complete vs. incomplete classpath

• With the closed-world assumption, we can guarantee that no linking errors are thrown at run time. This is currently the default.
• --allow-incomplete-class-path turns the build-time check to a run-time check. Currently global for the whole image. Many libraries set the option.
• Several places use the flag to decide between "throw an exception in the image builder" or "synthesize Graal IR that throws an exception at run time". For example in the bytecode parser:

  graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/phases/SharedGraphBuilderPhase.java

  Line 255 in cf56a33

  private void handleUnresolvedType(JavaType type) {

How to improve?

• The default must be switched to "allow incomplete class path".
• Use modules as the granularity for configuration? Can we assume all libraries that need configuration are proper modules?
• Create a report all possible linking errors to all auditing?
• Some discussion in the comments of Remove some limitations of GraalVM Native Image #2762
• Allow incomplete classpath configuration to be more granular #3929

Open Discussion

Possible deep dive topics for next meeting

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

• GC policy and GC performance (got a "vote" in the previous meeting)
• Reflection configuration: "query only" vs. "allow invocation" configuration for methods
• Conditional reflection configuration

[zakkak]

+1 for "GC policy and GC performance" as the deep dive topic of the next meeting

Thanks @christianwimmer !

[Sanne]

Regarding "How to improve?" for incomplete classpath

To share here for those who didn't make it at the meeting: as I've pointed out during the call, Quarkus has no plans to require Java modules for its libraries, so we would highly prefer a flag which focuses on the package or jar file - or the higher granularity, to explicitly list all missing symbols which should not be treated as compile errors.

It was mentioned that other frameworks rely on "uber jars" which would make the jar-centric flag less useful; in fact Quarkus offers this option as well but it's not the preferred one, and we don't use this packaging format when building a native-image, and I hope that other frameworks would see the benefits of avoiding the uber jar approach as well, as its convenience is only a point for JVM based distributions of the application. I think we can all agree that when producing a native image it's an unnecessary step; we also highlighted the approach introduces severe maintainability concerns so while I don't deny it's nice to have such options, I don't think we should focus on this approach as being the one to recommend for production use cases.

Having a marker within the affected library (within its jar) seems like a sensible compromise: in case of the library being repackaged ("shaded") and combined with other code, at worst the marker would extend as well to the additional code it's combined with; in extreme cases it would propagate to the whole application, converging into the current semantics. But this would be a choice of granularity that framework developers and application packaging can control and opt-in (opt-out).

I also maintain that it would be great - for any specific library - to list which code is "allowed to be missing" with an exhaustive list. This would prevent such flags to unintentionally get applied on other cases it was not intended for, and helps with long term maintenance of such metadata correctness.

[christianwimmer]

PR with a proposed solution: #4305