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. ------------- Commit messages: - Fixup comments after renaming - Rename functions with their side effects - jvmti GetAllModules requires holder to be kept alive - jvmti GetLoadedClasses requires holder to be kept alive - 8326820: Metadata artificially kept alive Changes: https://git.openjdk.org/jdk/pull/19769/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19769&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326820 Stats: 112 lines in 22 files changed: 21 ins; 26 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/19769.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19769/head:pull/19769 PR: https://git.openjdk.org/jdk/pull/19769
