Why try this?
Establish the reference measurement for origin/main before trying allocation reductions.
+
+
+
+ baseline
+ AR-00 · reference
+ Baseline
+
+
+ Allocation4,088,736B—
+ CPU median60.006ms—
+ Wall median22.995msRelay output equivalent unless noted
+
+
+ What changed?
Measured the mixed JVM/core SDK workload with fake Relay. Baseline emitted 132 envelopes: 120 events, 6 logs, and 6 transactions.
Result
Reference point for all candidate comparisons. GC was 0 collections / 0.0ms.
+
+
+ Patch-style diff reference
+# No patch. Baseline commit: 5dee26ba7ca9931bca62b730b210e01063e1c2d1
+# Workload output: 132 envelopes (event:120, log:6, transaction:6).
+
+
+
+ kept
+ AR-01 · kept
+ Avoid Scope defensive copies + use HashMap in CombinedScopeView
+
+
+ Allocation4,042,104B−46,632B / −1.14% vs baseline
+ CPU median47.770ms−12.236ms / −20.39% vs baseline; passed
+ Wall median20.311ms−2.684ms / −11.67% vs baseline; Relay output equivalent
+
+
+ Why try this?
Scope.getTags() and getAttributes() copied thread-safe internal maps on every read. CombinedScopeView also built short-lived merged maps as ConcurrentHashMap, even though the merged view is transient.
What changed?
Return the internal Scope maps directly and use HashMap for CombinedScopeView merged tags, extras, and attributes.
Result
Kept. Allocation improved by ~46KB and CPU/wall were faster than baseline in this run. Later safety review found the raw internal map return was not acceptable API behavior, so that portion was reverted after the experiment batch.
+
+
+ Patch-style diff actual commit 06d34e023f
+diff --git a/sentry/src/main/java/io/sentry/CombinedScopeView.java b/sentry/src/main/java/io/sentry/CombinedScopeView.java
+@@
+ import java.util.ArrayList;
++import java.util.HashMap;
+ import java.util.Collection;
+@@
+-import java.util.concurrent.ConcurrentHashMap;
+@@
+ public @NotNull Map<String, String> getTags() {
+- final @NotNull Map<String, String> allTags = new ConcurrentHashMap<>();
++ final @NotNull Map<String, String> allTags = new HashMap<>();
+@@
+ public @NotNull Map<String, SentryAttribute> getAttributes() {
+- final @NotNull Map<String, SentryAttribute> allAttributes = new ConcurrentHashMap<>();
++ final @NotNull Map<String, SentryAttribute> allAttributes = new HashMap<>();
+@@
+ public @NotNull Map<String, Object> getExtras() {
+- final @NotNull Map<String, Object> allTags = new ConcurrentHashMap<>();
++ final @NotNull Map<String, Object> allTags = new HashMap<>();
+
+diff --git a/sentry/src/main/java/io/sentry/Scope.java b/sentry/src/main/java/io/sentry/Scope.java
+@@
+ public @NotNull Map<String, String> getTags() {
+- return CollectionUtils.newConcurrentHashMap(tags);
++ return tags;
+ }
+@@
+ public @NotNull Map<String, SentryAttribute> getAttributes() {
+- return CollectionUtils.newConcurrentHashMap(attributes);
++ return attributes;
+ }
+
+
+
+ discarded
+ AR-02 · discarded
+ Use ArrayDeque for CombinedScopeView breadcrumbs merge
+
+
+ Allocation4,034,544B−54,192B / −1.33% vs baseline
+ CPU median58.561ms−1.445ms / −2.41% vs baseline; failed guardrail
+ Wall median26.926ms+3.931ms / +17.10% vs baseline; Relay output equivalent
+
+
+ Why try this?
The combined breadcrumb queue is transient. The idea was to avoid CircularFifoQueue + SynchronizedQueue overhead when only a short-lived merged queue is needed.
What changed?
Replace the Scope.createBreadcrumbsList helper call with an ArrayDeque in CombinedScopeView.getBreadcrumbs().
Result
Discarded. It saved a small amount of allocation, but CPU and wall time exceeded the 10% guardrail. It also risked subtly changing circular-capacity behavior.
+
+
+ Patch-style diff reconstructed patch-style diff (discarded worktree change was reset)
+diff --git a/sentry/src/main/java/io/sentry/CombinedScopeView.java b/sentry/src/main/java/io/sentry/CombinedScopeView.java
+@@
+ import java.util.ArrayList;
++import java.util.ArrayDeque;
+@@
+ Collections.sort(allBreadcrumbs);
+
+- final @NotNull Queue<Breadcrumb> breadcrumbs =
+- createBreadcrumbsList(scope.getOptions().getMaxBreadcrumbs());
++ final @NotNull Queue<Breadcrumb> breadcrumbs =
++ new ArrayDeque<>(scope.getOptions().getMaxBreadcrumbs());
+ breadcrumbs.addAll(allBreadcrumbs);
+
+ return breadcrumbs;
+
+
+
+ discarded
+ AR-03 · discarded
+ Remove Contexts deep-copy in applyScope only
+
+
+ Allocation4,037,688B−51,048B / −1.25% vs baseline
+ CPU median58.364ms−1.642ms / −2.74% vs baseline; failed guardrail
+ Wall median23.218ms+0.223ms / +0.97% vs baseline; Relay output equivalent
+
+
+ Why try this?
SentryClient.applyScope created new Contexts(scope.getContexts()) just to iterate entries. That deep-cloned context objects before immediately copying selected entries again.
What changed?
Iterate scope.getContexts().entrySet() directly in three applyScope variants.
Result
Discarded as a standalone attempt. The change was correct, but too small and hit CPU/wall noise guardrails. It was later kept as part of AR-04 with the tags/extras double-copy removal.
+
+
+ Patch-style diff reconstructed from later kept patch
+diff --git a/sentry/src/main/java/io/sentry/SentryClient.java b/sentry/src/main/java/io/sentry/SentryClient.java
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+ if (!contexts.containsKey(entry.getKey())) {
+ contexts.put(entry.getKey(), entry.getValue());
+ }
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+ if (!contexts.containsKey(entry.getKey())) {
+ contexts.put(entry.getKey(), entry.getValue());
+ }
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+ if (!contexts.containsKey(entry.getKey())) {
+ contexts.put(entry.getKey(), entry.getValue());
+ }
+
+
+
+ kept
+ AR-04 · kept
+ Eliminate applyScope double-copy for tags, extras, and contexts
+
+
+ Allocation4,024,504B−64,232B / −1.57% vs baseline
+ CPU median48.180ms−11.826ms / −19.71% vs baseline; passed
+ Wall median21.522ms−1.473ms / −6.41% vs baseline; Relay output equivalent
+
+
+ Why try this?
applyScope wrapped scope maps in new HashMap before passing them into setters that already copy internally. Contexts were also deep-copied just to iterate.
What changed?
Pass scope maps directly to setters and iterate contexts directly. This keeps the setter-owned copy while removing the redundant outer copy.
Result
Kept. Allocation improved by ~17.6KB with CPU/wall inside guardrails.
+
+
+ Patch-style diff actual commit f053b24f50
+diff --git a/sentry/src/main/java/io/sentry/SentryClient.java b/sentry/src/main/java/io/sentry/SentryClient.java
+@@
+ if (event.getTags() == null) {
+- event.setTags(new HashMap<>(scope.getTags()));
++ event.setTags(scope.getTags());
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+@@
+ if (replayEvent.getTags() == null) {
+- replayEvent.setTags(new HashMap<>(scope.getTags()));
++ replayEvent.setTags(scope.getTags());
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+@@
+ if (sentryBaseEvent.getTags() == null) {
+- sentryBaseEvent.setTags(new HashMap<>(scope.getTags()));
++ sentryBaseEvent.setTags(scope.getTags());
+@@
+ if (sentryBaseEvent.getExtras() == null) {
+- sentryBaseEvent.setExtras(new HashMap<>(scope.getExtras()));
++ sentryBaseEvent.setExtras(scope.getExtras());
+@@
+- for (Map.Entry<String, Object> entry : new Contexts(scope.getContexts()).entrySet()) {
++ for (Map.Entry<String, Object> entry : scope.getContexts().entrySet()) {
+
+
+
+ discarded
+ AR-05 · discarded
+ Remove MainEventProcessor options-tags double-copy
+
+
+ Allocation4,026,512B−62,224B / −1.52% vs baseline
+ CPU median62.548ms+2.542ms / +4.24% vs baseline; failed guardrail
+ Wall median23.473ms+0.478ms / +2.08% vs baseline; Relay output equivalent
+
+
+ Why try this?
MainEventProcessor.setTags used new HashMap(options.getTags()) before calling an event setter, matching the same double-copy pattern as AR-04.
What changed?
Pass options.getTags() directly to event.setTags().
Result
Discarded. The benchmark has no option-level tags, so the change produced no measurable allocation win and CPU noise exceeded the guardrail.
+
+
+ Patch-style diff reconstructed patch-style diff
+diff --git a/sentry/src/main/java/io/sentry/MainEventProcessor.java b/sentry/src/main/java/io/sentry/MainEventProcessor.java
+@@
+ private void setTags(final @NotNull SentryBaseEvent event) {
+ if (event.getTags() == null) {
+- event.setTags(new HashMap<>(options.getTags()));
++ event.setTags(options.getTags());
+ } else {
+ for (Map.Entry<String, String> item : options.getTags().entrySet()) {
+
+
+
+ discarded
+ AR-06 · discarded
+ Lazy-init Breadcrumb.data, first attempt
+
+
+ Allocation3,988,704B−100,032B / −2.45% vs baseline
+ CPU median68.422ms+8.416ms / +14.03% vs baseline; failed guardrail
+ Wall median26.424ms+3.429ms / +14.91% vs baseline; Relay output equivalent
+
+
+ Why try this?
Most benchmark breadcrumbs had no data. Each breadcrumb still eagerly allocated a ConcurrentHashMap for data.
What changed?
Initialize data as Collections.emptyMap(), create a HashMap only on first setData(), and use HashMap for copied/deserialized breadcrumb data.
Result
Discarded on the first run because CPU/wall exceeded guardrails despite a large allocation win. The same change was retried as AR-10 and kept, showing measurement noise was significant.
+
+
+ Patch-style diff reconstructed from AR-10 kept patch
+diff --git a/sentry/src/main/java/io/sentry/Breadcrumb.java b/sentry/src/main/java/io/sentry/Breadcrumb.java
+@@
+-import java.util.concurrent.ConcurrentHashMap;
++import java.util.HashMap;
+@@
+- private @NotNull Map<String, @NotNull Object> data = new ConcurrentHashMap<>();
++ private @NotNull Map<String, @NotNull Object> data = Collections.emptyMap();
+@@
+- final Map<String, Object> dataClone = CollectionUtils.newConcurrentHashMap(breadcrumb.data);
+- if (dataClone != null) {
+- this.data = dataClone;
++ if (!breadcrumb.data.isEmpty()) {
++ this.data = new HashMap<>(breadcrumb.data);
+@@
+- @NotNull Map<String, Object> data = new ConcurrentHashMap<>();
++ @NotNull Map<String, Object> data = new HashMap<>();
+@@
++ if (data.isEmpty() && data == Collections.EMPTY_MAP) {
++ data = new HashMap<>();
++ }
+ data.put(key, value);
+@@
+- CollectionUtils.newConcurrentHashMap(
++ CollectionUtils.newHashMap(
+
+
+
+ discarded
+ AR-07 · discarded
+ Lazy-init SpanContext tags and data maps
+
+
+ Allocation4,021,888B−66,848B / −1.63% vs baseline
+ CPU median48.781ms−11.225ms / −18.71% vs baseline; passed but too small / requested discard
+ Wall median20.529ms−2.466ms / −10.72% vs baseline; Relay output equivalent
+
+
+ Why try this?
SpanContext eagerly allocates ConcurrentHashMap instances for tags and data. The hypothesis was that many spans do not write both maps.
What changed?
Start tags/data as empty maps and allocate ConcurrentHashMap on first write.
Result
Discarded. It saved only ~2.6KB because TransactionContext.fromPropagationContext uses a constructor path that still eagerly creates data. Complexity was not worth the small win.
+
+
+ Patch-style diff reconstructed patch-style diff
+diff --git a/sentry/src/main/java/io/sentry/SpanContext.java b/sentry/src/main/java/io/sentry/SpanContext.java
+@@
+- protected @NotNull Map<String, @NotNull String> tags = new ConcurrentHashMap<>();
++ protected @NotNull Map<String, @NotNull String> tags = Collections.emptyMap();
+@@
+- protected @NotNull Map<String, Object> data = new ConcurrentHashMap<>();
++ protected @NotNull Map<String, Object> data = Collections.emptyMap();
+@@
+ public void setTag(final @Nullable String name, final @Nullable String value) {
+@@
+- this.tags.put(name, value);
++ if (tags.isEmpty() && tags == Collections.EMPTY_MAP) {
++ tags = new ConcurrentHashMap<>();
++ }
++ this.tags.put(name, value);
+@@
+- data.put(key, value);
++ if (data.isEmpty() && data == Collections.EMPTY_MAP) {
++ data = new ConcurrentHashMap<>();
++ }
++ data.put(key, value);
+
+
+
+ kept
+ AR-08 · kept
+ Short-circuit CombinedScopeView.getBreadcrumbs()
+
+
+ Allocation4,003,984B−84,752B / −2.07% vs baseline
+ CPU median48.176ms−11.830ms / −19.71% vs baseline; passed
+ Wall median19.565ms−3.430ms / −14.92% vs baseline; Relay output equivalent
+
+
+ Why try this?
The common workload had breadcrumbs in only one scope. The old code always allocated a list, copied all queues, sorted, created a circular queue, wrapped it, and copied again.
What changed?
If exactly one scope has breadcrumbs, return that queue directly. Only do the full merge path when multiple scopes contain breadcrumbs.
Result
Kept. Allocation improved by ~84.8KB and wall time improved by ~15% vs baseline.
+
+
+ Patch-style diff actual commit b78d163120
+diff --git a/sentry/src/main/java/io/sentry/CombinedScopeView.java b/sentry/src/main/java/io/sentry/CombinedScopeView.java
+@@
+ public @NotNull Queue<Breadcrumb> getBreadcrumbs() {
++ final @NotNull Queue<Breadcrumb> globalBc = globalScope.getBreadcrumbs();
++ final @NotNull Queue<Breadcrumb> isolationBc = isolationScope.getBreadcrumbs();
++ final @NotNull Queue<Breadcrumb> currentBc = scope.getBreadcrumbs();
++
++ // Fast path: only one scope has breadcrumbs (common case)
++ final boolean hasGlobal = !globalBc.isEmpty();
++ final boolean hasIsolation = !isolationBc.isEmpty();
++ final boolean hasCurrent = !currentBc.isEmpty();
++
++ if (!hasGlobal && !hasCurrent) {
++ return isolationBc;
++ }
++ if (!hasIsolation && !hasCurrent) {
++ return globalBc;
++ }
++ if (!hasGlobal && !hasIsolation) {
++ return currentBc;
++ }
++
++ // Multiple scopes have breadcrumbs — full merge
+ final @NotNull List<Breadcrumb> allBreadcrumbs = new ArrayList<>();
+- allBreadcrumbs.addAll(globalScope.getBreadcrumbs());
+- allBreadcrumbs.addAll(isolationScope.getBreadcrumbs());
+- allBreadcrumbs.addAll(scope.getBreadcrumbs());
++ allBreadcrumbs.addAll(globalBc);
++ allBreadcrumbs.addAll(isolationBc);
++ allBreadcrumbs.addAll(currentBc);
+
+
+
+ discarded
+ AR-09 · discarded
+ Use ArrayList instead of CopyOnWriteArrayList in CombinedScopeView
+
+
+ Allocation4,006,192B−82,544B / −2.02% vs baseline
+ CPU median53.368ms−6.638ms / −11.06% vs baseline; failed guardrail
+ Wall median19.982ms−3.013ms / −13.10% vs baseline; Relay output equivalent
+
+
+ Why try this?
CombinedScopeView lists are read-only transient merged views. CopyOnWriteArrayList avoids concurrent modification but is expensive when writes occur.
What changed?
Use ArrayList for attachments and event processor merged lists.
Result
Discarded. Attachments were empty and event processor lists were small, so CopyOnWriteArrayList overhead did not matter in this workload.
+
+
+ Patch-style diff reconstructed patch-style diff
+diff --git a/sentry/src/main/java/io/sentry/CombinedScopeView.java b/sentry/src/main/java/io/sentry/CombinedScopeView.java
+@@
+-import java.util.concurrent.CopyOnWriteArrayList;
+@@
+- final @NotNull List<Attachment> allAttachments = new CopyOnWriteArrayList<>();
++ final @NotNull List<Attachment> allAttachments = new ArrayList<>();
+@@
+- final @NotNull List<EventProcessor> allEventProcessors = new CopyOnWriteArrayList<>();
++ final @NotNull List<EventProcessor> allEventProcessors = new ArrayList<>();
+@@
+- final @NotNull List<EventProcessorAndOrder> allEventProcessors = new CopyOnWriteArrayList<>();
++ final @NotNull List<EventProcessorAndOrder> allEventProcessors = new ArrayList<>();
+
+
+
+ kept
+ AR-10 · kept
+ Lazy-init Breadcrumb.data, retry
+
+
+ Allocation3,967,752B−120,984B / −2.96% vs baseline
+ CPU median47.970ms−12.036ms / −20.06% vs baseline; passed
+ Wall median18.248ms−4.747ms / −20.64% vs baseline; Relay output equivalent
+
+
+ Why try this?
AR-06 showed a strong allocation win but failed CPU/wall due to noisy timing. Retrying tested whether the allocation win was real.
What changed?
Same lazy Breadcrumb.data idea: default to Collections.emptyMap(), allocate HashMap only on first data write, and avoid ConcurrentHashMap for copy/deserialization paths.
Result
Kept. This became the recorded best: 3,967,752B allocated, −120,984B / −2.96% vs baseline. Relay output remained equivalent.
+
+
+ Patch-style diff actual commit 065ea67cfb
+diff --git a/sentry/src/main/java/io/sentry/Breadcrumb.java b/sentry/src/main/java/io/sentry/Breadcrumb.java
+@@
+ import java.io.IOException;
+ import java.util.ArrayList;
++import java.util.HashMap;
+ import java.util.Collections;
+@@
+- private @NotNull Map<String, @NotNull Object> data = new ConcurrentHashMap<>();
++ private @NotNull Map<String, @NotNull Object> data = Collections.emptyMap();
+@@
+- final Map<String, Object> dataClone = CollectionUtils.newConcurrentHashMap(breadcrumb.data);
+- if (dataClone != null) {
+- this.data = dataClone;
++ if (!breadcrumb.data.isEmpty()) {
++ this.data = new HashMap<>(breadcrumb.data);
+@@
+- @NotNull Map<String, Object> data = new ConcurrentHashMap<>();
++ @NotNull Map<String, Object> data = new HashMap<>();
+@@
+ } else {
++ if (data.isEmpty() && data == Collections.EMPTY_MAP) {
++ data = new HashMap<>();
++ }
+ data.put(key, value);
+@@
+- if (key == null) {
++ if (key == null || data.isEmpty()) {
+ return;
+@@
+- CollectionUtils.newConcurrentHashMap(
++ CollectionUtils.newHashMap(
+
+
+
+ discarded
+ AR-11 · discarded
+ Return unmodifiable Scope maps instead of raw internals
+
+
+ Allocation3,973,696B−115,040B / −2.81% vs baseline
+ CPU median84.465ms+24.459ms / +40.76% vs baseline; failed guardrail
+ Wall median47.107ms+24.112ms / +104.86% vs baseline; Relay output equivalent
+
+
+ Why try this?
AR-01 returned raw internal maps, which saved copies but exposed mutable Scope internals. This attempted to keep the allocation win without allowing external mutation.
What changed?
Return Collections.unmodifiableMap(tags/attributes) from Scope getters.
Result
Discarded by measurement and then fully reverted for API safety. The run showed severe CPU/wall regression noise. Final tracked state restored defensive copies for Scope.getTags() and getAttributes().
+
+
+ Patch-style diff actual commit 9af1d54600; later reverted by e65556f610
+diff --git a/sentry/src/main/java/io/sentry/Scope.java b/sentry/src/main/java/io/sentry/Scope.java
+@@
+ public @NotNull Map<String, String> getTags() {
+- return tags;
++ return Collections.unmodifiableMap(tags);
+ }
+@@
+ public @NotNull Map<String, SentryAttribute> getAttributes() {
+- return attributes;
++ return Collections.unmodifiableMap(attributes);
+ }
+
+
+
+ final
+ AR-12 · not benchmarked
+ Safety revert: restore defensive Scope copies
+
+
+ Allocationnot measurednot measured
+ CPU mediannot measurednot measured
+ Wall mediannot measuredRelay output equivalent unless noted
+
+
+ Why try this?
The public Scope getters should not expose mutable internals. After AR-11 was discarded, the safest final code restored the original defensive-copy behavior.
What changed?
Reverted Scope.getTags() and getAttributes() to CollectionUtils.newConcurrentHashMap(...).
Result
Final worktree no longer contains AR-01’s risky raw-map getter behavior. The remaining final diff contains Breadcrumb.data lazy-init, CombinedScopeView HashMap/ breadcrumb fast path, and SentryClient applyScope copy reductions.
+
+
+ Patch-style diff actual commit e65556f610; corrective change after measured attempts
+diff --git a/sentry/src/main/java/io/sentry/Scope.java b/sentry/src/main/java/io/sentry/Scope.java
+@@
+ public @NotNull Map<String, String> getTags() {
+- return Collections.unmodifiableMap(tags);
++ return CollectionUtils.newConcurrentHashMap(tags);
+ }
+@@
+ public @NotNull Map<String, SentryAttribute> getAttributes() {
+- return Collections.unmodifiableMap(attributes);
++ return CollectionUtils.newConcurrentHashMap(attributes);
+ }