MemorySegment for fields

[Jorn Vernee]

That's an interesting idea!

The idea of being able to wrap arbitrary objects came to mind in the 
past, but memory segments are contiguous, and at the time at least I 
think the concern was that objects may not always be contiguous, or that 
we don't want to expose memory in between writable fields by accident.

But, for a single primitive field, wrapping it in a MemorySegment should 
be okay I think.

WRT read-only/final fields. Since we allow segments wrapping heap 
objects to be passed to native code (which you can do with the 
critical() option), we can't guarantee that the native code won't write 
to the memory any ways. So, if we go there, I think we'd be limited to 
mutable fields. Although, if native code writes out-of-bounds, it could 
already scribble on other parts of the Java heap, so maybe writing to 
mutable fields is just more of the same. Downcalls are a restricted 
operation after all.

Jorn

On 19/01/2024 22:48, David Lloyd wrote:
> I've been experimenting quite a bit with the FFM API and one thing 
> I've noted is that it would be nice to be able to get a 
> `MemorySegment` for a field on an object and/or a static field.
>
> In the former case, the use case would be to provide a very small 
> buffer for operations which may need one (for example, reading/writing 
> an `eventfd` on Linux, reading/writing single bytes, or capturing 
> `errno` without having to allocate a segment for every operation).
>
> The latter could be useful to send constant read-only data into a 
> native call, but this is more hypothetical than practical.
>
> I don't see much difference in terms of safety/integrity between a 
> hypothetical instance field-backed `MemorySegment` compared to one 
> backed by a heap array; it's essentially the same concept (and you can 
> achieve a sort-of-similar result today by wrapping a one-element array 
> with a `MemorySegment`, in another constant field, but the overhead is 
> one extra heap object in this case). The field could be required to be 
> non-final, or perhaps a final field could be wrapped using a read-only 
> `MemorySegment`.
>
> Could this be a reasonable enhancement?
> --
> - DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240119/99b5a2f1/attachment.htm>