[
https://issues.apache.org/jira/browse/CASSANDRA-21528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18098814#comment-18098814
]
koo commented on CASSANDRA-21528:
---------------------------------
I found a similar pattern in
org.apache.cassandra.db.ClusteringBoundOrBoundary.Serializer#deserialize. It
also shows the same memory consumption in profiling. But it is very small, so
it looks less urgent than this one.
Thanks :)
> Cache Enum.values() in ClusteringPrefix.Kind deserialization to avoid
> per-read array allocation
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21528
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
> Reporter: koo
> Assignee: koo
> Priority: Normal
> Fix For: 6.x, 7.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *description*
> When deserializing clusterings and range/slice bounds, the kind is resolved
> via Kind.values()[in.readByte()]:
> - ClusteringPrefix.java:616 — ClusteringPrefix.Deserializer (streaming
> path) // 5.0.7
>
> Enum.values() creates a new copy of its array every time it is called. So
> each time we read a clustering or a bound, a new Kind[] array is created just
> to look up one value by index, and then thrown away. This runs on the hot
> deserialization path, so it creates a lot of short-lived garbage for no real
> benefit.
>
> Impact (measured, JFR allocation profiling on a read/Paxos-LWT-heavy
> workload):
> - Total heap allocation observed: ~170 GB (120s)
> - ClusteringPrefix$Kind[]: ~5.22 GB (≈3.1%) of that total
> This garbage is short-lived, so GC pause impact under a modern collector is
> minimal and CPU cost is negligible; this is purely an allocation-pressure /
> GC-throughput improvement.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
