Arena/Segment allocator and zero initialized MemorySegment

[Pedro Lamarão]

Em qua., 5 de jun. de 2024 às 12:38, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> escreveu:


> > As far as i understand what an Arena is, an Arena is virtual, it's not
> > contiguous memory*, so supporting deallocation is possible (i'm not
> > saying it should) and having a way to ask for a zero initialized
> > MemorySegement is also something possible (again, not saying it should).
>
> While asking for _really really_ zero initialized segment is something
> that can be done, supporting deallocation of lone segments in an arena
> is not what the Arena API is about. All segments in the arena share the
> same lifetime, so they are either all alive, or all dead. This is what
> makes it possible to deal with cases where you have pointers in a struct
> referring to another struct safely (because if both structs came from
> the same arena, it's easy to prove everything works as it should). Once
> you start deallocating only _some_ things inside an arena, you are back
> to the same usability issues that malloc/free have (meaning that whether
> an Arena is alive or not, it doesn't really matter much, given that
> segments can go away at any time). So no, that's not something that I'd
> consider "possible", as it would violate the very essence of the
> contract that Arena is trying to establish.
>

This use case seems to be that of C++ std::allocator or perhaps
std::pmr::polymorphic_allocator.
Also, that of libraries such as OpenSSL, that allow the user to define the
"allocator" used internally for dynamic memory.
This suggests a FooAllocator interface with methods to allocate and
deallocate.
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.
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.
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.
The case of Netty's ByteBufAllocator comes to mind:
https://netty.io/4.1/api/io/netty/buffer/ByteBufAllocator.html

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240605/5c9e9220/attachment.htm>