MemorySegment for fields

[Maurizio Cimadamore]

Hi David,
it is a good suggestion, and the API has been designed with that kind of 
thing in the back of our mind - for instance, at some point we changed 
`MemorySegment::array` to `MemorySegment::heapBase`, as it seems clear 
that, especially in the case of Valhalla, the distinction between arrays 
and a tuple of flattened values becomes very thin.

As you mention there are some things to work out - for instance 
constructing such a segment might require a method handle lookup (to 
make sure that the field is accessible). As you mention there's also the 
problem with making the segment read-only, and working out whether such 
segments can be passed directly to foreign functions (using the Critical 
linker option).

But yes, overall it seems workable.

Maurizio

On 19/01/2024 21: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/2accb4c9/attachment-0001.htm>