captureCallState versus critical

[David Lloyd]

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/20240718/55e5b42c/attachment.htm>