Currently, ByteBuffer always allocates in powers of 2 which makes sense. But many allocators have a small amount of overhead which means the actual space reservation might be even bigger, possibly another power of two, often unnecessarily.
For example the following could happen:
The user needs to write 9,000 bytes and asks for allocator.buffer(capacity: 9_000)
ByteBuffer gets a malloc(16_384) (power of 2)
libc's allocator has (for the example's sake) 16 bytes of overhead storing some metadata
This means we now require 16384 (for the malloc) + 16 bytes (allocator overhead) = 16394 which isn't a power of two
This could yield to an extra page being mapped for nothing (we only needed 9000 bytes after all). NIO's ByteBuffer should probably allocate just under the next power of two to leave some slack for the allocator in case it needs it. Needs investigation.
This becomes even more important if/when ByteBuffer is able to use tail allocations.
Currently, ByteBuffer always allocates in powers of 2 which makes sense. But many allocators have a small amount of overhead which means the actual space reservation might be even bigger, possibly another power of two, often unnecessarily.
For example the following could happen:
allocator.buffer(capacity: 9_000)
malloc(16_384)
(power of 2)This could yield to an extra page being mapped for nothing (we only needed 9000 bytes after all). NIO's ByteBuffer should probably allocate just under the next power of two to leave some slack for the allocator in case it needs it. Needs investigation.
This becomes even more important if/when ByteBuffer is able to use tail allocations.