Comments on SegmentAllocator and ResourceScope
Stig Rohde Døssing
stigdoessing at gmail.com
Sun May 16 15:39:42 UTC 2021
Hi,
JEP 412 adds a new interface for allocating segments called
SegmentAllocator (great idea!), and I have a few questions regarding the
API and implementation as they exist in the foreign-jextract branch.
1: The ArenaAllocator block and max alloc sizes are hard coded. Is this
intended to be permanent, or will the block size become a parameter of
ArenaAllocator later? I'm not sure why it makes sense to hard code these
parameters? As far as I can tell, this will cause issues for at least the
bounded arena allocator, since requests above MAX_ALLOC_SIZE would cause
calls to newSegment, which throws an error.
2: The MAX_ALLOC_SIZE constant also seems strange. It is set to half the
block size, and any requests for segments above that size cause a fresh
segment to be allocated. I understand why it makes sense to allocate a new
segment if the request is larger than the block size, but if the request is
smaller than the block size, why is not good enough to check if there's
room in the current segment, and if so, return the appropriate slice, even
if the request exceeds half the block size?
See
https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java#L14-L15
3: Is the SegmentAllocator interface intended to support more advanced
memory pooling, such as pools where segments can be returned to the pool
after use? If so, how will the application indicate to the pool that a
segment can be returned? The Javadoc for MemorySegment and ResourceScope
discourage implementations outside the JDK, so the pool will not be able to
e.g. use wrapper classes to make "freed" segments return to the pool.
4: ResourceScope has the Handles concept, which are objects that are
acquired from the scope, which will cause the "close" method to fail (and
throw exceptions) until they are released. Would it make sense to make
Handles Autocloseable, to allow them to be used with try-with-resources? It
seems like it is always an error to acquire and not release a handle.
5: The ResourceScope Javadoc indicates that Handles exist to help avoid
concurrency errors where one thread frees memory currently being accessed
by another thread. It says that the thread closing the scope should not
repeatedly call ResourceScope.close until no exceptions are thrown, but
should instead use proper synchronization mechanisms, e.g. Handles to
coordinate. How will the thread closing the scope use handles to
coordinate? I don't see any methods on ResourceScope that allows the
closing thread to avoid calling "close" on a scope with open handles. Will
the closing thread just have to call "close" and hope for the best?
Thanks for reading.
More information about the panama-dev
mailing list