That would still be a design bug / logic flaw.
> On Jan 12, 2026, at 8:06 AM, Viktor Klang <[email protected]> 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 <[email protected]> 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 >
