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

[Alex Otenko]

Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the
problem with that? We'll swap it back in, when the VT can continue. Deal? :)

On Wed, 31 Jul 2024, 23:22 Alex Otenko, <oleksandr.otenko at gmail.com> wrote:

> I think you may need to revisit heap dump format. It is all best effort to
> capture JVM state, not actual state, and not true memory representation.
> Like, the pointers are 64 bit, even if compressed oops are in use, ...
>
> I've seen heap dumps with missing stack traces and missing GC roots. So,
> no, I don't think we should worry too much about objects that get optimised
> away.
>
> Side-effecting finalizers bug me. But if you can reclaim memory without
> executing them, I think it may be fine. After all, that's the behaviour of
> the program where the object is still alive.
>
> On Wed, 31 Jul 2024, 23:03 robert engels, <robaho at icloud.com> wrote:
>
>> As a follow-up, even if the heap dump could show the A instance - what
>> about inspection of its fields? Or if you trace its back references what is
>> its root?
>>
>> A virtual thread may not be a GC root, but it’s stack data has to be or
>> every monitoring/analysis technique is broken - and systems will be
>> impossible to audit.
>>
>>
>> On Jul 31, 2024, at 4:59 PM, robert engels <robaho at icloud.com> wrote:
>>
>> 
>> Yes, but it’s a graph, because if A doesn’t have a finalizer but
>> references something that does you face the same problem.
>>
>> I think it will. R very hard to profile / debug applications if this were
>> to come to pass. So I open a profiler and expect to see and instance of A
>> but I don’t, and I don’t see any log message (assume finally block printed
>> something) - am I just suppose to assume… well it was a virtual thread and
>> it “vanished” because it couldn’t make progress.
>>
>> That is ludicrous imo. And also completely unnecessary and against 20
>> plus years of Java design.
>>
>> On Jul 31, 2024, at 4:23 PM, Alex Otenko <oleksandr.otenko at gmail.com>
>> wrote:
>>
>> 
>>
>> I think your observation about finalizers is important. But without
>> finalizers - how do you detect that the object is not alive?
>>
>> More broadly - it is not the object that matters; the code must behave
>> like if the object were alive. (Think of unwrapped Optionals and Integers)
>>
>> On Wed, 31 Jul 2024, 22:03 robert engels, <robaho at icloud.com> wrote:
>>
>>> This analysis is incorrect. The guarantees about program order say that
>>> ‘a’ must be alive OR the finally block must execute. There is no gray area
>>> here. This MUST hold.
>>>
>>> You don’t even need to references GC roots - the specification considers
>>> reachability from instance of Thread. A VirtualThread extends Thread so
>>> proper OO means it must act as a Thread for all behaviors of Thread.
>>>
>>> On Jul 31, 2024, at 1:29 PM, Michal Domagala <outsider404 at gmail.com>
>>> wrote:
>>>
>>> 
>>> Documentation says: "The finally block always executes when the try
>>> block exits"
>>> Not "The finally block always executes"
>>>
>>> I think there are 3 areas to seek an answer about correct VT behavior.
>>>
>>> First is general, "sky-level" rules. GC rule says that "what is
>>> unreferenced and is not GC root, is collectable". The rule says that VT
>>> should be collectable, but many may contest that the rule - as very generic
>>> - is not applicable for blocked VT. But the rule works: blocked VT is
>>> successfully GC-able, if only observability is off.
>>>
>>> Second is habits. I agree that there is a habit that "finally block" is
>>> always executed. But maybe it is just a habit? I think VT GC case in
>>> something fresh and cannot be matched to existing experience, but if do
>>> "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power,
>>> "finally block" is not executed
>>>
>>> Third is common sense. If something is unreachable, better reclaim
>>> resources and pray it works than have a memory leak and countdown to OOM.
>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240731/ec3721b9/attachment.htm>