StephanEwen commented on issue #11109: [FLINK-15758][MemManager] Release segment and its unsafe memory in GC Cleaner URL: https://github.com/apache/flink/pull/11109#issuecomment-587415461 > An alternative to the private constructor could be our internal implementation of java.nio.ByteBuffer, which could be similar to DirectByteBuffer but this is a bit tedious. Nothing else comes into my mind atm. I think this does not work. aside from the fact that this sounds like a very high-touch solution, the main reason why memory segment needs to interoperate with ByteBuffer is for I/O, and the NIO stack can only access the memory directly if it finds a DirectByteBuffer. > Not sure, these changes are directly related to the warnings. They may be related. If we want to keep `MemorySegment` and `DirectByteBuffer` interoperability (for the above reason), then we may have to consider that in the GC design. For example, Netty seems to not use unsafe memory allocation and manual cleaners any more in Java 9+. Instead, they start with a big DirectByteBuffer (arena or chunk) from which they slice smaller buffers and then turn them into ByteBufs. So the starting/entry point is always `ByteBuffer`.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
