<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Many (all?) of the nifty solutions can be built on top of the
current one. The problem is the allocation bottleneck, so let's
focus on that first. I think the most straight-forward solution is
to use a better allocator. The one in the default Arenas is quite
generic. For instance, you could create a global free list
specifically dedicated to capture state segments. (Or, as
suggested, use the built-in Java heap allocator).<br>
</p>
<p>> thread locals and virtual threads do not get along very
well, for one thing<br>
</p>
<p>If the thread local was holding some kind of heavy resource,
having one per virtual thread (of which there might be millions)
would be problematic. For holding a single 4 to 12 byte memory
segment, maybe not so much? But, it might also be possible for us
to expose a per platform thread (not vthread) free list.<br>
</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 18-7-2024 21:13, David Lloyd wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANghgrQJ=RCTPerzZwXKGHLxLZqjjVDSLCj-ECQB=NYJVH23cA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for
filing the bug!<br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In practice my
strategy would likely be to keep the errno value with a class
that I can already guarantee is single-threaded through other
means (thread locals and virtual threads do not get along very
well, for one thing). Today this would mean something which is
attached to the object and would share its lifespan.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Another way to
slice this onion could be to allow the captured errno state
(for example) to be ejected from the method call before it
returns, by passing in something like an `IntConsumer`, or
even a setter `MethodHandle` which I could (for example)
extract from a field `VarHandle` and bind to my object
instance. This would be quite nifty.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In all these
solutions we're probably talking about more heap allocations,
at least until/unless Valhalla somehow saves the day, but at
least they *are* on-heap, meaning I don't have to have
cleaners for every one (which would probably get expensive).
The point would be to minimize the amount of things that need
to be set up and/or copied at invocation time, and to minimize
the amount of GC bookkeeping as well, if possible.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jul 18, 2024 at
11:50 AM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">jorn.vernee@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hey David,</p>
<p>This was a restriction that arose during development of
the critical feature, because we weren't sure if oops
would stay valid across the native call. But, since we
don't transition to the native thread state, oops stay
valid. So, I think we could technically relax the
restriction. I'm not 100% sure if it's safe to read/write
to errno (and Windows equivalents) from the java thread
state though. I've filed [1]<br>
</p>
<p>Either way though, the Java heap buffer you'd use to
capture the state would always escape, so you would always
get an allocation. Re-using an off-heap buffer may work
better (as long as it's not shared between threads, maybe
cached in a thread-local).<br>
</p>
<p>Jorn</p>
<p>[1]: <a href="https://bugs.openjdk.org/browse/JDK-8336768" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8336768</a><br>
</p>
<div>On 18-7-2024 18:07, David Lloyd wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">One of
the very first things I tried to do with the FFM API
was to call (unistd.h) `read` on a non-blocking file
with a small heap buffer. Of course, I was immediately
rebuffed: it is not allowed to capture `errno` from
critical methods (including those which access the
heap).</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What is
the reason for this restriction, and is there a
possibility that it could be relaxed in the future?
Having to allocate (possibly tiny) off-heap memory for
any operation that may set `errno` is a difficult
restriction in terms of usability.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks!</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">- DML • he/him<br>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">- DML • he/him<br>
</div>
</div>
</blockquote>
</body>
</html>