8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT

[jovanstevanovic]

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.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT

Reviewers

• Joe Wang (@JoeWang-Java - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5331/head:pull/5331
$ git checkout pull/5331

Update a local copy of the PR:
$ git checkout pull/5331
$ git pull https://git.openjdk.java.net/jdk pull/5331/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5331

View PR using the GUI difftool:
$ git pr show -t 5331

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5331.diff

[bridgekeeper]

Hi @jovanstevanovic, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user jovanstevanovic" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

@jovanstevanovic The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[jovanstevanovic]

/signed

[mlbridge]

Webrevs

• 01: Full (2e8a90c6)
• 00: Full (652bcaf1)

[AlanBateman]

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.

[jovanstevanovic]

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.

It seems that both repositories for Xalan on Apache's GH (https://github.com/apache/xalan-java and https://github.com/apache/xalan-j) are inactive for two and a half years.

[JoeWang-Java]

Yeah, there hasn't been any major activities (i.e. a minor release) for 7 years. It's also true that the JDK has diverged.

[openjdk]

⚠️ @jovanstevanovic the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout jovanstevanovic/improving-xslt-support-for-native-image
$ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
$ git push

[openjdk]

@jovanstevanovic This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT

Reviewed-by: joehw

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 27 new commits pushed to the master branch:

• d4177a9: 8273351: bad tag in jdk.random module-info.java
• ec9d1be: 8273194: Document the two possible cases when Lookup::ensureInitialized returns
• 81d2ace: 8273369: Computing micros between two instants unexpectedly overflows for some cases
• efe3ed1: 8273358: macOS Monterey does not have the font Times needed by Serif
• e58c12e: 8273512: Fix the copyright header of x86 macroAssembler files
• 461a467: 8273456: Do not hold ttyLock around stack walking
• 695b434: Merge
• 4afbcaf: 8273592: Backout JDK-8271868
• a37254c: 8271868: Warn user when using mac-sign option with unsigned app-image.
• c464f09: 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply
• ... and 17 more: https://git.openjdk.java.net/jdk/compare/f6cc1732f47672cea413fa842c4f106c1314c626...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@JoeWang-Java) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[jovanstevanovic]

@JoeWang-Java We need to backport this to JDK 11 as well. How can we do that? Also, is there anything else I should do to merge these changes after approval?

[JoeWang-Java]

I'm not involved in any older releases. You'll need to find the right channel for a particular backport you want to make and ask there. As for merging the change in the current release, please update the copyright header and the LastModified date for each of the classes. The github interface unfortunately won't allow me to add comments directly to the unchanged code area. Once that's done, you'll need to issue an integrate command. I'll sponsor your change.

[jovanstevanovic]

I'm not involved in any older releases. You'll need to find the right channel for a particular backport you want to make and ask there. As for merging the change in the current release, please update the copyright header and the LastModified date for each of the classes. The github interface unfortunately won't allow me to add comments directly to the unchanged code area. Once that's done, you'll need to issue an integrate command. I'll sponsor your change.

Okay, I'll take a look for a proper channel. Also, copyright headers and LastModified dates are not up to date.

[JoeWang-Java]

The headers look good now. Thanks.

[jovanstevanovic]

The headers look good now. Thanks.

Great!

[jovanstevanovic]

/integrate

[JoeWang-Java]

/sponsor

[openjdk]

@JoeWang-Java The change author (@jovanstevanovic) must issue an integrate command before the integration can be sponsored.

[openjdk]

@jovanstevanovic
Your change (at version 2e8a90c) is now ready to be sponsored by a Committer.

[jovanstevanovic]

@JoeWang-Java Looks like the OpenJDK bot is bugging, so I think you need to comment again with the same sponsor command.

[JoeWang-Java]

/sponsor

[openjdk]

Going to push as commit f690a01.
Since your change was applied there have been 28 commits pushed to the master branch:

• 5e1df2c: 8273162: AbstractSplittableWithBrineGenerator does not create a random salt
• d4177a9: 8273351: bad tag in jdk.random module-info.java
• ec9d1be: 8273194: Document the two possible cases when Lookup::ensureInitialized returns
• 81d2ace: 8273369: Computing micros between two instants unexpectedly overflows for some cases
• efe3ed1: 8273358: macOS Monterey does not have the font Times needed by Serif
• e58c12e: 8273512: Fix the copyright header of x86 macroAssembler files
• 461a467: 8273456: Do not hold ttyLock around stack walking
• 695b434: Merge
• 4afbcaf: 8273592: Backout JDK-8271868
• a37254c: 8271868: Warn user when using mac-sign option with unsigned app-image.
• ... and 18 more: https://git.openjdk.java.net/jdk/compare/f6cc1732f47672cea413fa842c4f106c1314c626...master

Your commit was automatically rebased without conflicts.

[openjdk]

@JoeWang-Java @jovanstevanovic Pushed as commit f690a01.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.