8342283: CDS cannot handle a large number of classes

[iklam]

When lots of classes are loaded during java -Xshare:dump, the internal arrays used by some of the HashMaps and ArrayLists become too large to be archived by CDS (> 256KB).

At the very end of Java bytecode execution during java -Xshare:dump, we used to call clear() on these tables to free their elements (*) -- these tables are repopulated at run time when classes are loaded incrementally. However, the clear() call doesn't resize the internal arrays.

The fix is to re-ininitialize these tables to new, empty tables that have small internal arrays.

===
(*) the call to resetArchivedStates() is made from HeapShared::reset_archived_object_states()

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8342283: CDS cannot handle a large number of classes (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21797/head:pull/21797
$ git checkout pull/21797

Update a local copy of the PR:
$ git checkout pull/21797
$ git pull https://git.openjdk.org/jdk.git pull/21797/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21797

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21797.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back iklam! 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 change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@iklam 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.

[mlbridge]

Webrevs

• 01: Full (42296ac6)
• 00: Full (0320ba93)

[rose00]

As has been discussed elsewhere, this is an unusual but legitimate use of @Stable.
The simple rule is don't store any value that you would not want the JIT to remember forever (as a compile time constant). In fact, store only one value, in most cases. But you can also store several values (perhaps because of tolerated races) as long as you can tolerate any of the values showing up in the JIT code.

In the case of the AOT cache, the VM compiler does not constant fold stable vars when creating AOT code at cache assembly. With this "fine print", we see that stable vars are allowed to be rather unstable in the assembly phase, as long as they stabilize before the VM compiler starts compiling JIT code in the production run.

I suppose this should be written out better, for maintainers of code which uses stable vars.

[shipilev]

When we reworked memory barriers for @Stable fields (JDK-8333791), we had a discussion on memory model implications of @Stable. There were competing proposals, but we have settled on "@Stable behave like final-s, in order to provide safety margin for uses where we accidentally rely on this property for some final-like fields". This change introduces such the "accident", AFAICS.

[shipilev]

I wonder if moving all this to VM side, which is not bound to Java language rules, would be conceptually cleaner. It would be more work, but I think there any only three classes that implement resetArchivedStates, which limits the scope of the change. I am prototyping this locally...

[shipilev]

Something like this: master...shipilev:jdk:JDK-8342283-cds-reset-archived-states. This passes runtime/cds at least.

[bridgekeeper]

@iklam 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]

@iklam 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.