Designing a new concurrent data structure
questdb.ioDirectByteBuffer would allow direct pointer access to the backing memory. When used with allocateDirect, you can rely on Java's GC to manage the memory. Not sure if it's a perfect fitnfor the use case but it's simpler to reason about.
DirectByteBuffer exhibits an intriguing behavior: it deallocates its backing memory during the finalization process, which occurs after garbage collection cycles. This poses an issue if your system is conservative with on-heap allocations, leading to infrequent GC cycles. In such cases, there could be a significant delay between the time the memory becomes unreferenced and when it is actually deallocated. This behavior could, in some respects, mimic a memory leak.
This is why some libraries hacks into DirectByteBuffer to deallocate memory explicitly, bypassing the finalizer altogether. For instance, the Netty library has implemented such a workaround: https://github.com/netty/netty/blob/795db4a866401aa172757b95...