[
https://issues.apache.org/jira/browse/CASSANDRA-20428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935022#comment-17935022
]
Jon Haddad commented on CASSANDRA-20428:
----------------------------------------
That's what I thought too at first, because it doesn't expose anything on the
Arena itself. But I believe you can keep an arena around indefinitely, and per
request, [create a memory
segment|https://docs.oracle.com/en/java/javase/22/core/memory-segments-and-arenas.html]
over the Arena's memory using the
[PrefixAllocator|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/foreign/SegmentAllocator.html#prefixAllocator(java.lang.foreign.MemorySegment)],
then use the SlicingAllocator to hand out allocations for the duration of the
request. At the beginning of the next request, we'd hit the prefix allocator
line again, giving us a reusable memory area that can handle most (all?)
objects that are allocated per-request.
We can also add our own
[SegmentAllocator|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/foreign/SegmentAllocator.html]
with whatever conveniences we want.
I plan on taking a closer look at this, because if we can get it to work,
there's really no reason to manually manage and juggle memory for either
requests or compaction.
> Eliminate byte array allocation in ByteArrayAccessor.read
> ---------------------------------------------------------
>
> Key: CASSANDRA-20428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20428
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Jon Haddad
> Priority: Normal
> Attachments: allocation-reverse.html,
> image-2025-03-11-11-05-55-378.png
>
>
> During compaction we allocate a new byte[] in ByteArrayAccessor.read. This
> is one of the hottest paths in the codebase, hit during writes, compaction,
> creating tables, and possibly others. In my performance tests using default
> compaction settings of 64MB I see this responsible for 40% of allocations.
> This is largely what drives GC pause frequency and duration. If we are able
> to eliminate the O(N) allocations performed here, this might be one of the
> best optimizations we could do for the number of things it touches.
> Allocation profile attached.
> !image-2025-03-11-11-05-55-378.png|width=514,height=269!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
