On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic <github.com+44313413+jovanstevano...@openjdk.org> wrote:
> GraalVM Native Image supports loading classes at runtime if they are known > during image build (class predefinition). This is achieved by the JVMTI agent > that registers dynamically generated classes in a regular HotSpot run. The > Native Image build uses these registered classes to embed them into the > produced binary so they can be loaded at runtime. Loading at runtime is > achieved by matching the unique hash of generated classes. > > If the generated bytecode is unstable across runs, the generated native image > can not match the hash of the runtime-generated bytecode to the pre-defined > classes. The execution failure happens here: > > https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/PredefinedClassesSupport.java#L127-L131. > > In XSLT the produced bytecode is unstable for the following reasons: > > - Methods like ` HashMap#values` and `HashMap#keySet` result in different > traversal orders of its elements yielding a different order of methods and > fields. > > - The default `Object#toString` includes the current memory reference of > `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated > class. I guess a question here will be whether this should be contributed to the upstream Xalan project to keep the changes in the JDK in sync, or maybe the JDK has diverged too much already for this to matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/5331
