<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi David,<br>
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.</p>
<p>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).</p>
<p>But yes, overall it seems workable.</p>
<p>Maurizio<br>
</p>
<div class="moz-cite-prefix">On 19/01/2024 21:48, David Lloyd wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANghgrRfiQfPtkjyy2nkXaOXXUp-rNDhW6bUtd6nH9YHUE2q8A@mail.gmail.com">
<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>
</blockquote>
</body>
</html>