8261090: Store old classfiles in static CDS archive

[shiyuexw]

8261090: Store old classfiles in static CDS archive

---

Progress

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

Issue

• JDK-8261090: Store old classfiles in static CDS archive

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk11u-dev pull/856/head:pull/856
$ git checkout pull/856

Update a local copy of the PR:
$ git checkout pull/856
$ git pull https://git.openjdk.java.net/jdk11u-dev pull/856/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 856

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk11u-dev/pull/856.diff

[bridgekeeper]

👋 Welcome back shiyuexw! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 01: Full - Incremental (2c0b5935)
• 00: Full (0b531ce0)

[shiyuexw]

Thanks a lot for the suggestion.
As described in JDK-8230413, there are still large number of existing classes with older class version (< 50) in real world applications. Those classes are missing the benefit of CDS. For better use of AppCDS, we requested the backport.
We have run all the test cases under hotspot/jtreg/runtime/appcds includes these new cases in this patch,
and run some demos which has old classifies, such as spring-petclinic.
We have submitted a new patch to revert the change for for JDK-8266822 and JDK-8267431

[tstuefe]

Hi @shiyuexw,

Decision is not up to me, so just my personal opinion. But I have strong reservations about downporting this patch:

• it is large and complex. It's a lot of Reviewer work taken away from other issues.
• its effects are difficult to estimate. Even if this patch was working flawlessly, we'd now run with a much larger number of old classes getting stored in application archives, which means CDS and the VM runtime exercised in a lot new ways. This may destabilize 11u by shaking bugs lose we have not encountered yet or may have not been down ported yet.
• It's also difficult to test. Because the real behavior difference will show up only in applications using large amounts of very old class files <JDK6. To get good test coverage we'd need some large scale tests for scenarios like that.
• Since Oracle decided to not downport it in its closed 11u port, we'd now have a delta in a subsystem that is heavily modified in mainline and gets updates often.
• IIUC you write that this proposed patch is really a patch collection, containing 8266822 and 8267431 too. We normally downport patches 1:1.

It would be another story if Oracle had already downported it too, then we would have much a stronger incentive.

We have run all the test cases under hotspot/jtreg/runtime/appcds includes these new cases in this patch,
and run some demos which has old classifies, such as spring-petclinic.

Sorry, I don't think this is enough by a long stretch. I'd need tier1-n tests across the board, across the whole range of supported platforms and architectures. We'd also like to see large scale tests with systems that use large amounts of pre-JDK6 classes.

Bottomline, in my eye there is not a large enough benefit to justify the cost and risk involved. I think the workarounds we have are acceptable: users can just run JDK17 or should update their class libraries or just have to live without them in AppCDS.

Sorry, I know you put a lot of work in. When in doubt, before attempting a large backport, it is better to discuss it on the OpenJDK mailing lists to see what folks think.

Cheers, Thomas

[shiyuexw]

Hi Thomas,

Thanks a lot for your comment.

I understand your concern, and understand it will be difficult to accept this enhancement being ported to JDK11.
In actual work, it is difficult for us to ask customers to update their libraries, especially some third-party libraries.
This is why we request this backport.
We have run the tier1, tier2, tier3 cases on linux x86 and aarch64, and revert the other commits in this PR.

Thanks again for your advice.

[bridgekeeper]

@shiyuexw This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@shiyuexw This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.