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)
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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21797#issuecomment-2449027257
