RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT [v2]

Joe Wang joehw at openjdk.java.net
Thu Sep 9 15:59:10 UTC 2021


On Thu, 9 Sep 2021 12:25:17 GMT, Jovan Stevanovic <github.com+44313413+jovanstevanovic at 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.
>
> Jovan Stevanovic has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8273278: Improving XSLT support for GraalVM's Native Image.

Marked as reviewed by joehw (Reviewer).

The headers look good now. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5331


More information about the core-libs-dev mailing list