On Thu, 31 Oct 2024 03:52:16 GMT, Ioi Lam <ik...@openjdk.org> wrote: > 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()](https://github.com/openjdk/jdk/blob/688e92e7f5febddd2935cb7f500dd3f10fbd9401/src/hotspot/share/cds/metaspaceShared.cpp#L799)
src/java.base/share/classes/java/lang/ClassLoader.java line 302: > 300: // Note: VM also uses this field to decide if the current class > loader > 301: // is parallel capable and the appropriate lock object for class > loading. > 302: private @Stable ConcurrentHashMap<String, Object> parallelLockMap; When we reworked memory barriers for `@Stable` fields ([JDK-8333791](https://bugs.openjdk.org/browse/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. src/java.base/share/classes/java/lang/ClassLoader.java line 2737: > 2735: * @implNote This is done while the JVM is running in > single-threaded mode, > 2736: * and at the very end of Java bytecode execution. We know that no > more classes > 2737: * will be loaded and none of the fields modified by this method > will be used again. 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... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21797#discussion_r1824040989 PR Review Comment: https://git.openjdk.org/jdk/pull/21797#discussion_r1824125608
