On Tue, 18 Jun 2024 13:33:55 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the >> iterators which are not designed to be used by the GC also keep the holder >> of the CLDs alive and by extensions keeps all metadata alive. This is >> problematic for concurrent GC as it keeps otherwise unreachable classes from >> being unloaded and the respective metadata freed. >> >> This patch changes the default iteration behaviour to not keep the holder >> alive, with the exception of `loaded_classes_do` (renamed >> `loaded_classes_do_keepalive`) and `modules_do` (renamed >> `modules_do_keepalive`) which is used by jvmti APIs that requires that the >> holder is kept alive. >> >> All other uses consumes all the metadata it queries during its safepoint or >> before releasing the `ClassLoaderDataGraph_lock`. >> >> Before this change some jcmd, new jfr chunks and some jfr events, all of >> which consumed these APIs, could cause class unloading to not occur. >> >> Been running our internal stress test in an even more stressful mode which >> without this patch reproduces the metaspace OOME >> [JDK-8326005](https://bugs.openjdk.org/browse/JDK-8326005) consistently >> within a few hours. And after this patch it does not. >> >> Currently running tier1-tier8 testing. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 2342: > >> 2340: >> 2341: // Iterate over all the modules loaded to the system. >> 2342: ClassLoaderDataGraph::modules_do_keepalive(&do_module); > > Looks like this code exposes an OopHandle backed by the CLD handle area, > which isn't a strong root that the GC will start tracing from. So it would > seem that we need to keep these oops alive somehow. `ClassLoaderDataGraph:: modules_do_keepalive ` is a `keepalive` iteration. That is it will load the holder of the CLD. https://github.com/openjdk/jdk/blob/08366b1244775e5892bbbb184660821e8774f37a/src/hotspot/share/classfile/classLoaderDataGraph.cpp#L302-L310 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19769#discussion_r1644739284
