<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>That's an interesting idea!</p>
<p>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.</p>
<p>But, for a single primitive field, wrapping it in a MemorySegment
should be okay I think.</p>
<p>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.<br>
</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 19/01/2024 22: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>