
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 17/05/2023 08:28, Uwe Schindler

      wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org">

      <li>You changed the lifetime abstractions in Java 20 and again in

        21. To me this is 2 rounds. After 19 people were not happy, so

        you added 20. In 20 there was some additional cleanup (in my

        impression it was a step back to Java 18 state just with

        different class names: MemorySession -> Arena).</li>

    </blockquote>

    <p>Another minor point (we discussed this before). While, it's true

      that Java 20 splits MemorySession into two abstractions and Java

      21 seems to merge things back onto one, in reality things are more

      subtle. Java 21 _still_ allows deallocation (and allocation) to be

      treated as a true capability: only code that has an Arena can

      close it (or allocate). This is **very** different from Java

      18/19, where you could always ask a segment its scope and then

      close it, and created an issue where libraries could not, in the

      default configuration of the FFM API, share segments freely with

      untrusted clients.</p>

    <p>The second very important difference is that Java 21, like Java

      20 allows clients to define custom arenas, which has always been

      one of the goals of the FFM API. As much as the JDK can try and

      define all the most common allocators, there will be always cases

      that will be left out. Allowing developers to define their own

      allocation scheme (as well as their own close policy) is IMHO a

      very big thing, and one we've been actively looking for after Java

      19.</p>

    <p>Again, I understand the frustration for having to deal with

      preview classfile versions and all. And I also understand that

      Lucene doesn't care about most of the stuff listed above (as I

      mentioend yesterday, the main thing for Lucene is the ability to

      close shared segments). But I also think we shouldn't fall into

      the trap of oversimplifying things: as explained, the memory API

      and the linker API have to work well together, and be flexible

      enough to handle use cases beyond what Lucene cares about (maybe,

      maybe not - perhaps one day Lucene will have its own wrappers

      around "mmap" using the Linker API :-) ). And we should, I think,

      make sure we get that balance right.</p>

    <p>Maurizio<br>

    </p>

    <p><br>

    </p>

  </body>

</html>