[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads

robert engels robaho at icloud.com
Thu Aug 1 09:41:53 UTC 2024


I was not aware of that! So are you saying that current JVMs will GC or not even create A in the following:

A a = …
while(true) {
  …never reference A…
}
a.doSomething();



> On Aug 1, 2024, at 4:21 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 25 Jul 2024, at 14:12, Robert Engels <robaho at icloud.com> wrote:
>> 
>> Here is a trivial example of why this must be so,
>> 
>> Thread A:
>> 
>> has WeakRef to object O.
>> 
>> Thread B:
>> 
>> Strong ref to object O.
>> 
>> B blocks indefinitely on a queue that becomes unreachable except by B.
>> 
>> … other operations X1..Xn..
>> 
>> B sets O to null.
>> 
>> ----
>> 
>> If B were “cleaned up” auto-magically, O would no longer have a strong reference, A would see that O no longer existed, and could assume because of happens-before relationship that operations X1…Xn completed - which would break the happens-before relationship guarantees. Doing so would break sequential consistency.
> 
> You seem to be under the impression that if a reference logically exists somewhere on a thread’s stack and the thread has not terminated, then the GC is not allowed to collect it. That is not the case. The GC is already allowed to collect objects that are referenced by a thread if the VM can prove that the thread will never access them again, so the assumption that this is not the case is misplaced. In fact, ReachbilityFence exists because your assumption is *not* generally guaranteed (and, indeed, not even kept) by the VM, not even for platform threads.
> 
> An object that will provably never be accessed again can be collected.
> 
> While we’re on the subject, it is a very bad idea to rely on logic based on weakrefs being enqueued. How WeakRefs behave is entirely dependent on the implemementation details of the particular GC, and they significantly differ from one another in that area. GCs don’t know when objects become unreachable, they’re not obligated to *ever* enqueue weak references, and even those that do may do that a very long time (and I don’t mean seconds) after an object becomes unreachable.
> 
> — Ron


More information about the loom-dev mailing list