<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 11:51 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p><br>
    </p>
    <div>On 12/03/2025 16:25, Brian Goetz wrote:<br>
    </div>
    <blockquote type="cite">
      
      <font size="4" face="monospace">That does seem like a more
        future-proof choice.  (I suspect too it would be less intrusive
        to adapt the internals to MS than BB.)</font><br>
    </blockquote>
    <p><font size="4" face="monospace">They are probably similar in
        spirit -- but at least you would know that the MS path is more
        aggressively/actively optimized.</font></p>
    <p><font size="4" face="monospace">I do share some of Chen's
        concerns -- random access on MS (and BB) is not comparable to
        random access on a byte[]. So changing the internals of the
        classfile API to use MS/BB is something that needs to be done
        carefully (and with benchmarks at hands).</font></p>
    <p><font size="4" face="monospace">One possible area where adopting
        a "more raw" buffer would be beneficial is when writing/reading
        custom attributes -- since BB/MS will already provide the
        primitives we need to access load/store primitive values from/in
        the buffer. But -- again, something that requires care and
        consideration, it's not a slam dunk.<br></font></p></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Internally, (on the parsing side at least) it is my expectation that we would not likely be able to get away with having a single, general access strategy using the `MemorySegment` API (but we could test that now, even without the suggested API changes - I would love to be wrong). It seems more likely that we'd want to keep the current array-based strategy (which uses `Unsafe` liberally) and add a new direct memory address-based access strategy (also using `Unsafe` in an equivalent manner), and select the strategy based on the kind of `MemorySegment` or `ByteBuffer`.</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">Having three parse and build APIs (one for each of `byte[]`, `ByteBuffer`, and `MemorySegment`) makes sense to me because there's a use case for each of them, and they can be implemented in terms of one another to a great extent which gives a lot of flexibility. Particularly, it seems to me that as long as `ClassLoader.defineClass(String,ByteBuffer,ProtectionDomain)` exists, then ByteBuffer should be floated up to the API, even if it ends up being e.g. `MemorySegment.ofByteBuffer()` on the inside. (That said, I wouldn't hate it if a new `defineClass` which uses `MemorySegment` could be defined someday.)</div></div></div><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"><br></span></div>-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>