<div dir="ltr"><div dir="ltr">Em qua., 5 de jun. de 2024 às 12:38, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> As far as i understand what an Arena is, an Arena is virtual, it's not <br>
> contiguous memory*, so supporting deallocation is possible (i'm not <br>
> saying it should) and having a way to ask for a zero initialized <br>
> MemorySegement is also something possible (again, not saying it should).<br>
<br>
While asking for _really really_ zero initialized segment is something <br>
that can be done, supporting deallocation of lone segments in an arena <br>
is not what the Arena API is about. All segments in the arena share the <br>
same lifetime, so they are either all alive, or all dead. This is what <br>
makes it possible to deal with cases where you have pointers in a struct <br>
referring to another struct safely (because if both structs came from <br>
the same arena, it's easy to prove everything works as it should). Once <br>
you start deallocating only _some_ things inside an arena, you are back <br>
to the same usability issues that malloc/free have (meaning that whether <br>
an Arena is alive or not, it doesn't really matter much, given that <br>
segments can go away at any time). So no, that's not something that I'd <br>
consider "possible", as it would violate the very essence of the <br>
contract that Arena is trying to establish.<br></blockquote></div><span class="gmail_signature_prefix"><div><br></div><div>This use case seems to be that of C++ std::allocator or perhaps std::pmr::polymorphic_allocator.</div><div>Also, that of libraries such as OpenSSL, that allow the user to define the "allocator" used internally for dynamic memory.<br></div><div>This suggests a FooAllocator interface with methods to allocate and deallocate.<br></div><div>I think one could argue this about FooAllocator, that it would be good for FooAllocator to be standardized, so that libraries/frameworks may normalize on it, so that users may easily define one FooAllocatorImpl for multiple libraries/frameworks.</div><div>But I think one could also argue that this need is very specialized and those users are very rare and everybody will just use the default, so the sum of the actual extra work will be small in the community of programmers.</div><div>Also, as this discussion suggests, what appears to be a universal interface may actually not be universal at all, and perhaps it is best to have libraries define their own allocator interfaces and see what emerges from that.</div><div><div>The case of Netty's ByteBufAllocator comes to mind:</div><div><a href="https://netty.io/4.1/api/io/netty/buffer/ByteBufAllocator.html">https://netty.io/4.1/api/io/netty/buffer/ByteBufAllocator.html</a><br></div><div><br></div></div>-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>