[External] : Re: captureCallState versus critical

[Jorn Vernee]

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).

 > thread locals and virtual threads do not get along very well, for one 
thing

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.

Jorn

On 18-7-2024 21:13, David Lloyd wrote:
> Thanks for filing the bug!
>
> 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.
>
> 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.
>
> 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.
>
> On Thu, Jul 18, 2024 at 11:50 AM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     Hey David,
>
>     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]
>
>     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).
>
>     Jorn
>
>     [1]: https://bugs.openjdk.org/browse/JDK-8336768
>
>     On 18-7-2024 18:07, David Lloyd wrote:
>>     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).
>>
>>     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.
>>
>>     Thanks!
>>     -- 
>>     - DML • he/him
>
>
>
> -- 
> - DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240719/ab83441d/attachment.htm>