On Thu, 8 Oct 2026 01:56:30 GMT, Shiv Shah <[email protected]> wrote:
> 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).
test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects003/referringObjects003.java
line 195:
> 193: // its handles to them a little later, so one collection may not
> be enough.
> 194: for (int i = 0; i < 5; i++) {
> 195: forceGC();
It'd be worth spelling this out in the comment: the retry works because the
handle is released in the meantime, i.e. it depends on the time forceGC()
takes. A lighter GC here would look like an obvious cleanup but would break the
fix.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33261#discussion_r4226231576
