<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The latter could be useful to send constant read-only data into a native call, but this is more hypothetical than practical.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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`.</div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Could this be a reasonable enhancement?</div></div><div>--<br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>