Native Image Committer and Community Meeting 2023-01-12

[christianwimmer]

List of all past and upcoming meetings: #3933

New and Noteworthy

• JDK 20 support is merged, everything should work on JDK 20
  5debbd8
  [GR-43182] Add support for JDK 20 CPU features. #5674
  [GR-42220] Support compiling substratevm with JDK 20. #5676

• [GR-42693] First draft of native-image bundle support. #5569 Implementation of "build bundle" support is close to finished, version in PR should be mostly functional already.

• Compatibility:
  [GR-36029] [GR-36060] Fix problems in case of incompatible class changes. #5745
  [GR-42628] Load predefined classes during class initialization. #5722

• Peak performance / memory footprint improvements:
  [GR-43138] [GR-43356] Use gaps in superclasses for fields, including monitor fields. #5735
  [GR-43013] Do more constant folding before analysis. #5732 Now String.value is properly constant folded to a stable array for constant strings

• Usability
  [GR-41912] More user-friendly reporting of internal errors. #5414
  [GR-43385] Group by modules and JARs in code area breakdown. #5705
  [GR-41268] Add automatic computation for Unsafe.staticFieldOffset() and Unsafe.staticFieldBase(). #5639

• Monitoring / tools:
  [GR-34179] Upgrade CE debug info feature to provide information about Java types for Windows/PECOFF. #5621

Deep Dive: How we handle the complication that the Java bytecode verifier does not check interface types

The Java bytecode verifier does not check variables (including method parameters and function return values) as well as fields that have an interface type, or an array of an interface type: even if they have an declared type of an interface, they are actually just treated as java.lang.Object. This means that the invokeinterface bytecode implementation needs to do a type check before the invoke, and also various other compiler optimizations cannot rely on interfaces. An IncompatibleClassChangeError must be thrown at run time when the receiver of an invokeinterface does not implement that interface.

In other words: in Java it is legal to "cast" any object to any interface type without violating type system rules. See this gem in the JDK as an example:
https://github.com/openjdk/jdk/blob/58aae340a9892889ef8784ef9360bb7e0af85ddd/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L2655
It casts an Object[] array (the result of the Set.toArray) to a Comparable[] array and passes that array to Arrays.sort(Comparable[] array).

Originally, Native Image was designed to fail at image build them when such interface type violations are detected, leveraging the static analysis. But over the years, these checks got weakend, and after the introduction of saturated type flows we were no longer detecting such problems at all. #5745 now adds complete and correct support.

There is one downside though: before every invokeinterface, an explicit type check is now inserted. This can lead to some peak performance regressions, especially in thight loops that do a lot of interface calls, for example Arrays.sort.

• Insertion of the type check:
  

  graal/compiler/src/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java

  Line 1598 in 6615100

  protected ValueNode maybeEmitIncompatibleClassChangeErrorCheck(ValueNode receiver, InvokeKind invokeKind, ResolvedJavaType referencedType) {

• Filtering out unchecked types in the static analysis:
  

  graal/substratevm/src/com.oracle.graal.pointsto/src/com/oracle/graal/pointsto/flow/TypeFlow.java

  Line 583 in 6615100

  public static AnalysisType filterUncheckedInterface(AnalysisType type) {

• Filtering out unchecked types in the compiler:
  

  graal/compiler/src/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/StampFactory.java

  Line 314 in 6615100

  public static StampPair forDeclaredType(Assumptions assumptions, JavaType returnType, boolean nonNull) {

#5745 also fixes another unrelated problem: when the receiver of an invoke does not implement the invoked method at all, an IncompatibleClassChangeError or one of its subclasses must be thrown. This is done using a synthetic method, i.e., we ensure that there is always an invokeable method even if it is missing in the .class file. Such problems can only occur with independent re-compilation of .java files.

Possible deep dive topics for next meeting

• Upcoming improvements to reflection configuration: distinguish between "method not found" and "method not registered for reflection".

Please send suggestions in the GraalVM Slack channel