<!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>