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. `/signed` ------------- PR: https://git.openjdk.java.net/jdk/pull/5331
