Before Creating the Enhancement Request
Summary
Reduce allocation in auxiliary store components by replacing boxed maps with primitive atomics, caching string keys, reusing StringBuilders, and optimizing timer wheel flush.
Motivation
JFR profiling reveals several allocation hotspots in auxiliary store components that run on every message:
QueueOffsetOperator — uses ConcurrentMap<String, Long> for queue offsets, boxing every long update into a Long object and requiring map lookups.BrokerStatsManager — buildStatsKey/topicQueueKey/consumerOffset methods create new strings on every call. incQueue* methods use Integer parameters causing autoboxing.IndexService — builds index keys with StringBuilder allocated per-call.TimerWheel — flushes all slots unconditionally, even when no changes occurred.
Describe the Solution You'd Like
QueueOffsetOperator: Replace ConcurrentMap<String, Long> with ConcurrentMap<String, AtomicLong> — eliminates boxing on every update.BrokerStatsManager: Cache buildStatsKey/topicQueueKey/consumerOffset string results. Change Integer parameters to int to eliminate autoboxing.IndexService: Reuse StringBuilder via ThreadLocal.TimerWheel: Add volatile dirty flag — skip flush when no changes since last flush.AppendMessageResult: Add constructor with pre-computed fields to avoid redundant allocation.
Describe Alternatives You've Considered
- Use
LongAdder instead of AtomicLong — AtomicLong is sufficient for moderate contention and provides get() for reads.
- Use
String.format cache — String.concat is faster for small fixed key patterns.
- Use object pool for
StringBuilder — ThreadLocal is simpler and thread-safe by design.
Additional Context
Part of a larger JFR-driven optimization effort. Related PRs: #10443, #10444, #10514, #10524, #10526.
Before Creating the Enhancement Request
Summary
Reduce allocation in auxiliary store components by replacing boxed maps with primitive atomics, caching string keys, reusing StringBuilders, and optimizing timer wheel flush.
Motivation
JFR profiling reveals several allocation hotspots in auxiliary store components that run on every message:
QueueOffsetOperator— usesConcurrentMap<String, Long>for queue offsets, boxing everylongupdate into aLongobject and requiring map lookups.BrokerStatsManager—buildStatsKey/topicQueueKey/consumerOffsetmethods create new strings on every call.incQueue*methods useIntegerparameters causing autoboxing.IndexService— builds index keys withStringBuilderallocated per-call.TimerWheel— flushes all slots unconditionally, even when no changes occurred.Describe the Solution You'd Like
QueueOffsetOperator: ReplaceConcurrentMap<String, Long>withConcurrentMap<String, AtomicLong>— eliminates boxing on every update.BrokerStatsManager: CachebuildStatsKey/topicQueueKey/consumerOffsetstring results. ChangeIntegerparameters tointto eliminate autoboxing.IndexService: ReuseStringBuildervia ThreadLocal.TimerWheel: Add volatiledirtyflag — skip flush when no changes since last flush.AppendMessageResult: Add constructor with pre-computed fields to avoid redundant allocation.Describe Alternatives You've Considered
LongAdderinstead ofAtomicLong—AtomicLongis sufficient for moderate contention and providesget()for reads.String.formatcache —String.concatis faster for small fixed key patterns.StringBuilder— ThreadLocal is simpler and thread-safe by design.Additional Context
Part of a larger JFR-driven optimization effort. Related PRs: #10443, #10444, #10514, #10524, #10526.