captureCallState versus critical

[Jorn Vernee]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240718/87b99982/attachment-0001.htm>