On 13/01/2026 07:45, Michael van Acken wrote:
Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <
[email protected]>:

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

Reply via email to