Why would that help? Even if you could “inspect” the producer thread, what would it tell you. It would have no object references and no stack trace. Yes, you’d have a name which could carry some information. You might be able to inspect its thread locals. But you can get the same debugging info with a simple logging statement at thread exit.
What I'm saying is that detecting, and debugging, such issues is
vastly more difficult when the forgotten thread has been GC:ed.
On 2026-01-12 12:31, Robert Engels
wrote:
No, just ensure that there is always a thread this
will eventually call unpark().
You can ensure this with proper use of
try/finally.
If you write that code any nothing ever calls
unpark - it is hung (and leaked). You can resolve this without
any new APIs.
In my example there is no queue. Are you suggesting that
all pre-existing code and all new code should get rewritten
using some new API?
On 2026-01-11 18:57, robert
engels wrote:
because if park wakes up, the thread already
has a reference to the queue meaning it can start another
thread that puts items into the queue. Meaning the queue
is not “unreferenceable”, so you can’t simply destroy a
thread waiting in park().
>This code is fundamentally broken. Park() can
wake up for any reason.
I don't see how "When park wakes up" (i.e. the
temporal aspect) affects correctness in any way in the
example given.
>I suggest you look at ClosableQueue - it is
correct and far easier to use.
The example is completely devoid of any queuing
concerns. We're talking about logic which is executed
by some thread, and the person who writes the code
does not strictly know whether that thread is a
platform thread, a pooled platform thread, a virtual
thread, an ephemeral virtual thread, a GC finalizer
thread.
In short, this is about: pre-existing code which may
get executed by an ephemeral virtual thread may silently
leak resources under certain circumstances. Now, it
can be argued that most of that code was "not ideal"
in the first place, but the big difference is that
when any such defect gets noticed in a running
application, there's a much better visibility if the
thread which ran into the problem is still there
(evidence) vs not (no evidence).
On 2026-01-11 01:50, Robert
Engels wrote:
This code is fundamentally broken.
Park() can wake up for any reason.
I suggest you look at ClosableQueue -
it is correct and far easier to use.
Hi Dmitry,
An example can look like:
void method() {
long fileDescriptor =
acquireFileDescriptor();
LockSupport.park();
releaseFileDescriptor(fileDescriptor);
}
If an ephemeral VT executes that method, and
there are no other references to that ephemeral
VT, then at the point of park(), nothing can
unpark it anymore, and it will then never
release the file descriptor.
>We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
I don't see how that can work in practice,
because it requires all users of your constructs
to be familiar about exactly how all third-party
logic (including JDK classes) are implemented
under the hood. Perhaps I'm misunderstanding?
On 2026-01-09 17:27,
Dmitry Zaslavsky wrote:
Not sure what you mean by native resources?
Do you mean what people would use like try resources?
We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
Which makes me think that there is a better way to express my point from before.
I think there is actually a common pattern here.
We use VT inside of the lib. We don’t want users to actually use any threads all.
I think it’s a goal of Alex as well.
We use VT as a way to avoid using threads (if that makes sense).
I think ScopedTasks is going in the same direction. Ideally user just doesn’t know there are threads.
We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
We don’t want users to think about Threads period.
So the thought of "GC roots on a VT … we don’t want that though to ever occur or we failed ;)
On Jan 9, 2026, at 10:26 AM, Viktor Klang <[email protected]> wrote:
On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
someCollection.apar.map { …. }
Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don’t need to rest of the code to run, it’s costly.
If the task are not actively mounted but previously started and are waiting… (in our case it’s LockSupport.park) we just want to drop that entire queue and everything around it….
How do you handle acquired native resources that are yet to be released?
--
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
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
|
