[
https://issues.apache.org/jira/browse/CASSANDRA-20428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934647#comment-17934647
]
Jon Haddad edited comment on CASSANDRA-20428 at 3/12/25 8:43 PM:
-----------------------------------------------------------------
Yes, agreed on the difficulty [~dcapwell]. This is one of the reasons I like
the idea using Arenas (JDK 21+ only). You don't need to keep references around.
I took a look at the code and I'm seeing this in ByteArrayAccessor:
{noformat}
@Override
public byte[] read(DataInputPlus in, int length) throws IOException
{
byte[] b = new byte[length];
in.readFully(b);
return b;
}
{noformat}
I don't have strong feelings on what the title is. I'm pointing to the top of
the stack where the allocation happens, that's what I want to see eliminated.
was (Author: rustyrazorblade):
Yes, agreed on the difficulty [~dcapwell]. This is one of the reasons I like
the idea using Arenas (JDK 21+ only). You don't need to keep references around.
I took a look at the code and I'm seeing this in ByteArrayAccessor:
{noformat}
@Override
public byte[] read(DataInputPlus in, int length) throws IOException
{
byte[] b = new byte[length];
in.readFully(b);
return b;
}
{noformat}
> 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]
