[External] : Re: Ephemeral threads
Robert Engels
rengels at ix.netcom.com
Mon Jan 12 14:14:35 UTC 2026
That would still be a design bug / logic flaw.
> On Jan 12, 2026, at 8:06 AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>
> The unparker thread doesn't have had to have exited, it just forgot whom to unpark.
>
>> On 2026-01-12 14:11, robert engels wrote:
>> I’m sorry - but I’m confused now. The primary cause of the issue is no unparkers left (which with ephemeral would mean that the waiters would “disappear” since they could never make progress. So the unparker thread must have exited - that is the source of the bug. Having the waiters just be GCd would break the language specification regarding try/finally. I understand that if the thread cannot make progress there should be no difference - but there is - because of details like weak references and finalizers- the system would be in an inconsistent state.
>>
>> So the proper solution is no to “disappear” the threads, but fix the prime issue of no unparkers.
>>
>>>> On Jan 12, 2026, at 7:00 AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>>>
>>> Why wouldn't it have a stack trace or object references? How would it be able to log something on thread exit if it never exits (it gets GC:ed).
>>>
>>>> On 2026-01-12 13:15, Robert Engels wrote:
>>>> It would have no object references and no stack trace.
>>> --
>>> Cheers,
>>> √
>>>
>>>
>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
>>>
> --
> Cheers,
> √
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
>
More information about the loom-dev
mailing list