Ephemeral threads

[Andrew Haley]

On 10/01/2026 15:42, Alan Bateman wrote:
> On 10/01/2026 11:04, Andrew Haley wrote:
>> :
>>
>> Maybe it's waiting on some kind of semaphore that has become
>> unreachable. In that case, the thread cannot make any progress. It
>> makes no difference whether you GC it or not. The native resources it
>> holds will never be released. Semantically, an unreachable thread is
>> not a thing: it has no properties.
>>
>> Therefore, any thread that is unreachable may be GC'd, surely.
>>
>> I guess I may be missing some way that an unreachable thread is
>> observable? If so, what is it?
>>
> Diagnosing resource leaks, semaphore permit "leaks" etc. is much harder
> if threads can be GC'ed before they terminate.
> 
> We looked into the implications of ephemeral threads a few years ago.
> Aside from being fragile to use, they lead to issues that range from
> mildly spooky to truly horrifying. Think of cleaners running when
> objects are in inconsistent state. Think of objects with finalizers that
> put a "goodbye" element to a queue and cause a thread to come back from
> the dead.

OK, I think I get it. The issue here is that a thread is unreachable but 
can be resurrected if it's finalized.

So, at some risk of flogging a dead horse, I'm wondering: what if we 
could figure out a way in which an unreachable thread could be GC'd, but 
only if it was honest-to-goodness unreachable, i.e. it wasn't on a 
reference queue and it had no finalizer. We'd be good, right?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671