Yes, as previously mentioned, there is a big impact on debuggability.
On 2026-01-12 15:14, Robert Engels wrote:
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
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
