On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> CDS cannot handle large number of classes, because `ClassLoader` data > structures get too large for CDS archival. The new test captures such an > occasion. We do `clear()`-s, but that is not enough to trim the backing > storages for the affected collections. > > In contrast with previous attempts to fix this > (https://github.com/openjdk/jdk/pull/21797 and my VM-side field overwrite), > we can just reinitialize the fields using `Unsafe`, which bypasses normal > `final` field write restriction. `ClassLoader` already does a similar thing > nearby! This allows us to stay fully in Java, and makes the patch fairly > straightforward. > > Additional testing: > - [x] Linux x86_64 server fastdebug, new test reliably fails without the > fix, passes with it > - [x] Linux x86_64 server fastdebug, `runtime/cds` src/java.base/share/classes/java/lang/ClassLoader.java line 2590: > 2588: * @implNote This is done while the JVM is running in > single-threaded mode, > 2589: * and at the very end of Java bytecode execution. We know that no > more classes > 2590: * will be loaded and none of the fields modified by this method > will be used again. There is a tiny technical debt here. If future AOT code generation uses a future aggressive constant folding of object fields (cf. `TrustFinalNonStaticFields`) and a constant CL reference ends up in optimized code and there is a constant-folded reference (and.. and…) it is remotely possible that the old value of the field will get wrongly embedded in AOT code. If we arrange AOT code generation to occur after all of these fixups (in Java code) are done, then the problem will not occur. It's a delicate set of invariants. Your expanded comment is a good start at calling them out, but this is a long string we are pulling on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24877#discussion_r2060872094
