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).

This PR looks good enough to move it out of draft state and publish.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/33261#issuecomment-6057655553

Reply via email to