[External] : Re: Ephemeral threads

[Andrew Haley]

On 13/01/2026 07:45, Michael van Acken wrote:
> Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <
> oleksandr.otenko at gmail.com>:
> 
>> Oh, ok, I confused it with something else. I recall dealing with a system
>> that would panic or report that there were fibers that were no longer going
>> to make progress.
>>
>> I think there are plenty of designs with generators, iterators and async
>> where non-termination is not a bug.
> 
> I have been thinking about this as well, what the difference between
> various perspectives/designs actually is.
> 
> My first and up to now only idea: a thread comes with hard promises about
> what things will happen in the future.
> 
> Its accumulated call/handler stack is a batch of unfinished business that
> is guaranteed to be worked upon.

That would be a major change to Java. People tend to assume that threads 
will make progress "eventually", but there can be no guarantees.

As Gil Tene wonderfully put it,

"If a system MUST be non-blocking, it should probably not be on the JVM, 
OS, Hypervisor, Hardware-that-uses-Power-management, 
Hardware-that-does-ECC, etc. Basically, non-blocking (systems) as 
opposed to algorithms or sets of threads only exit on paper, in the 
sense that if you have a system that MUST be non-blocking (as a system), 
you probably need to execute it on paper... ;-)"

I'm not absolutely certain if the rules about "premature collection" 
permit a thread to be garbage collected along with its referents before 
that thread is exited. JLS 12.6.2, Interaction with the Memory Model, 
says that once an object X is not _reachable_ it may be collected, then 
goes on to describe "All active uses of X in thread t that come after..."

I'd assume that if thread t is not reachable, and t is only thread that 
refers to X, then there are no active uses of X, and therefore X is not 
reachable, and so collection of X (and all that implies) is legal.

But we're not only talking about theoretical issues here, but also the 
principle of least astonishment.

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