Thomas Stuefe (###@###.###) from SAP purposed an alternative way to track Arena chunks:
2) allocation.cpp: If I understand it correctly, you track Arena size
changes (Arena::set_size_in_bytes()), and, separately from that, Chunk
allocation and destruction. That way you loose the information about
which chunk is associated with which Arena - you know chunk locations,
but not to which Arena they belong, or if they are pooled.
A different approach could be not to track arena size changes, but
chunk ownership change: when a chunk is handed out to an arena by the
ChunkPool, and when the chunk is returned to the ChunkPool. you could
track Chunk location and size together with Arena address - that way,
you'd know which chunk belongs to which arena and you could
reconstruct a memory layout with arena information.
I think it would come down to exact the same number of calls to the
memory tracker, only the tracked information would be richer. I don't
know though how much performance that would cost.
2) allocation.cpp: If I understand it correctly, you track Arena size
changes (Arena::set_size_in_bytes()), and, separately from that, Chunk
allocation and destruction. That way you loose the information about
which chunk is associated with which Arena - you know chunk locations,
but not to which Arena they belong, or if they are pooled.
A different approach could be not to track arena size changes, but
chunk ownership change: when a chunk is handed out to an arena by the
ChunkPool, and when the chunk is returned to the ChunkPool. you could
track Chunk location and size together with Arena address - that way,
you'd know which chunk belongs to which arena and you could
reconstruct a memory layout with arena information.
I think it would come down to exact the same number of calls to the
memory tracker, only the tracked information would be richer. I don't
know though how much performance that would cost.