Yohahaha commented on PR #5770: URL: https://github.com/apache/incubator-gluten/pull/5770#issuecomment-2116550590
After some tries I would like to say ReservationListener is a hook to another memory management system and should be as simple as possible, MemoryAllocator is a common class at top level which may be implemented with different allocate/reserved details, each supported native backend has its own memory management way and can compose both MemoryAllocator and ReservationListener. For this PR: 1. SparkAllocationListener aim to hook in Spark memory management system and do memory report work. 2. ListenableMemoryAllocator provide a specific allocator implementation at cpp module level which its memory changes can be tracked by listener. 3. VeloxMemoryManager track arrow memory usage by ListenableMemoryAllocator and velox part's memory usage by velox::memory::MemoryManager, memoryPoolTransferCapacity is velox's details and could be used in ListenableArbitrator. > Seems to be that the block reservation code can be very suitable to become a individual AllocationListener. Would you like to check on that? So I think the responsibility and boundaries of above classes are clear. -- 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. To unsubscribe, e-mail: commits-unsubscr...@gluten.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@gluten.apache.org For additional commands, e-mail: commits-h...@gluten.apache.org
