referringObjects003 stops its 15 threads, joins them, forces one collection and expects its ThreadGroup to be gone. That isn't guaranteed. A joined thread's Thread object is still held by the VM until its handles are released a bit later, and a terminated Thread keeps its group in holder.group. If the collection marks while a handle is still there the group survives it, the parent's weak reference to it stays and instances() counts it. ZGC with -Xcomp on a slow Windows debug run is where it showed up.
The test now forces the collection again until no test group or thread is left, five tries at most, then runs the same checks as before. When something is still there it prints the object's referrers, today the log only names the group. The helper querying instances() twice is a separate issue -------- Testing: - [x] referringObjects003, heapwalking001, heapwalking002, mixed001 and mixed002 on linux-x64 debug with the default collector and with -XX:+UseZGC, on windows-x64 debug with -XX:+UseZGC -Xcomp -XX:-TieredCompilation five times each, and tier1-3 on linux-x64. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Retry the collection until the test group is gone and log what still holds it Changes: https://git.openjdk.org/jdk/pull/33261/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=33261&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8393752 Stats: 32 lines in 1 file changed: 20 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/33261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33261/head:pull/33261 PR: https://git.openjdk.org/jdk/pull/33261
