<div dir="ltr"><div dir="ltr">Em qui., 3 de nov. de 2022 às 12:18, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    <p>On 03/11/2022 14:07, Radosław Smogura
      wrote:<br></p>
    <blockquote type="cite">
      
      
      
      <div>
        <p class="MsoNormal">Hi Maurizo,</p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Thank you for sharing this approach. I
          would have question related to closing arenas, and I was
          thinking about creating pooling arena which will return
          allocated segments back to the pool like in case of pooling
          allocator.</p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Firstly, minor thing, Arena class is sealed
          so I can’t create wrapper around it?</p>
      </div>
    </blockquote>
    I don't think Arena needs to be sealed, as there's nothing too magic
    about it. Opening it up allows clients to decorate arenas easily.
    But either way, it would be similarly easy for a client to define
    another class which implements both SegmentAllocator and
    AutoCloseable, which wraps an Arena.</div></blockquote><div><br></div><div>I agree it is easy to define an internal allocator interface in an application or framework.</div><div>Libraries, however, would be required to define their own, public allocator interface for configuration and mocking.</div><div>It is incredibly valuable for library authors to have common, universal interfaces defined by the platform for this sort of thing.<br></div><div>I believe @NotNull is the go-to example for this kind of missing shared definition.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>