Skip to content

Drop per-call String allocation in SharedDBCommenter.containsTraceComment#11734

Open
dougqh wants to merge 3 commits into
masterfrom
dougqh/dbcommenter-alloc
Open

Drop per-call String allocation in SharedDBCommenter.containsTraceComment#11734
dougqh wants to merge 3 commits into
masterfrom
dougqh/dbcommenter-alloc

Conversation

@dougqh

@dougqh dougqh commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

What This Does

Reduces allocation SQL comment injection, but removing unnecessary allocation during contains checks

Motivation

Reduce allocation overhead

Additional Notes

SharedDBCommenter.containsTraceComment built nine KEY + "=" needle strings on every call. The keys are static final but initialized via encode(...), so they are not compile-time constants — each KEY + "=" is a runtime concatenation. A non-matching comment ran all nine checks and allocated nine throwaway Strings per call.

This hoists the needles to *_EQ constants computed once at class init. The contains-chain is otherwise unchanged.

Measured

SharedDBCommenterBenchmark (added here) — JDK 25, @Threads(8), @Fork(5), -prof gc:

throughput gc.alloc.rate.norm
before (concat) 29.7M ± 1.7M ops/s 156 B/op
after (*_EQ) 55.4M ± 2.5M ops/s ≈ 0

~1.9× throughput, allocation eliminated. Per our usual approach the allocation win is surfaced as a throughput delta at @Threads(8) (GC is a shared-heap tax); -prof gc corroborates the mechanism (156 → 0 B/op). Numbers live in the benchmark's class Javadoc.

🤖 Generated with Claude Code

dougqh and others added 2 commits June 24, 2026 15:56
SharedDBCommenter.containsTraceComment built nine "KEY + =" strings on every
call: the keys are encode()-derived (not compile-time constants), so each
"KEY + =" is a runtime concat. A non-matching comment ran all nine checks and
allocated nine throwaway Strings per call. Precompute the needles once at class
init as *_EQ constants; the contains-chain is unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Throughput benchmark at @threads(8) over a realistic comment-content mix
(mostly non-DD, the all-nine-checks worst case) to surface the per-call
allocation removed by hoisting the "<key>=" needles to constants. Run the
parent commit (baseline) vs this branch and read the ops/s delta; -prof gc
(gc.alloc.rate.norm) corroborates the mechanism.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@dougqh dougqh added tag: performance Performance related changes tag: no release notes Changes to exclude from release notes type: refactoring comp: database Database Monitoring tag: ai generated Largely based on code generated by an AI or LLM labels Jun 24, 2026
@dougqh dougqh marked this pull request as ready for review June 24, 2026 20:51
@dougqh dougqh requested review from a team as code owners June 24, 2026 20:51
@dougqh dougqh requested review from mhlidd and vandonr and removed request for a team June 24, 2026 20:51
@dd-octo-sts

dd-octo-sts Bot commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

🟡 Java Benchmark SLOs — Performance SLO warning (near threshold)

Suite Status
Startup 🟡 warning

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results
Scenario Candidate master Δ (95% CI of mean)
startup:insecure-bank:iast:Agent 13.93 s 13.91 s [-0.7%; +0.9%] (no difference)
startup:insecure-bank:tracing:Agent 12.88 s 12.98 s [-1.5%; +0.0%] (no difference)
startup:petclinic:appsec:Agent 17.36 s 17.25 s [-0.3%; +1.6%] (no difference)
startup:petclinic:iast:Agent 16.70 s 17.56 s [-9.1%; -0.8%] (maybe better)
startup:petclinic:profiling:Agent 17.50 s 17.44 s [-0.6%; +1.3%] (no difference)
startup:petclinic:sca:Agent 17.44 s 17.43 s [-1.0%; +1.1%] (no difference)
startup:petclinic:tracing:Agent 16.52 s 16.66 s [-1.7%; +0.0%] (no difference)

Commit: 94261419 · CI Pipeline · Benchmarking Platform UI


Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

zulu-17 @fork(5), -prof gc: 33.5M -> 62.1M ops/s (~1.9x), 156 -> ~0 B/op.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@dougqh

dougqh commented Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

Benchmark results (zulu-17, JDK 17.0.7, @Threads(8), @Fork(5), -prof gc)

SharedDBCommenterBenchmark.containsTraceComment — the per-query check run during inject:

throughput gc.alloc.rate.norm
before (concat) 33.5M ± 2.0M ops/s 156 B/op
after (*_EQ) 62.1M ± 3.8M ops/s ~0 B/op (10⁻⁵)

Removing the per-call KEY + "=" concatenation drops allocation to ~0 and lifts throughput ~1.9× at @Threads(8) — the allocation win surfacing as throughput, exactly as intended. Benchmark Javadoc refreshed in 9426141.

@dougqh dougqh added this pull request to the merge queue Jun 25, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

/merge

@gh-worker-devflow-routing-ef8351

gh-worker-devflow-routing-ef8351 Bot commented Jun 25, 2026

Copy link
Copy Markdown

View all feedbacks in Devflow UI.

2026-06-25 18:17:31 UTC ℹ️ Start processing command /merge


2026-06-25 18:17:35 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).


2026-06-25 20:17:56 UTCMergeQueue: The build pipeline has timeout

The merge request has been interrupted because the build 1513741081229096535 took longer than expected. The current limit for the base branch 'master' is 120 minutes.

@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 25, 2026
@dougqh dougqh added this pull request to the merge queue Jun 26, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

/merge

@gh-worker-devflow-routing-ef8351

gh-worker-devflow-routing-ef8351 Bot commented Jun 26, 2026

Copy link
Copy Markdown

View all feedbacks in Devflow UI.

2026-06-26 02:48:06 UTC ℹ️ Start processing command /merge


2026-06-26 02:48:11 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).


2026-06-26 04:48:34 UTC 🚨 MergeQueue: This merge request is in error

error while getting head build completion result

Details

Error: There was an error while retrieving the result for pipeline 121199058

FullStacktrace:
child workflow execution error (type: mergequeue_private.MergeQueue_WaitForChecksOrUntilIsFinal, workflowID: 019f01d3-e019-71ad-adca-ac953e874519_72, runID: 019f01d4-438a-70fd-8c67-14b35b576488, initiatedEventID: 72, startedEventID: 73): child workflow execution error (type: mergequeue.MergeQueue_WaitForCompletionOfRef, workflowID: 019f01d4-438a-70fd-8c67-14b35b576488_8, runID: 019f01d4-4469-74d4-9748-02a48752b10e, initiatedEventID: 8, startedEventID: 10): There was an error while retrieving the result for pipeline 121199058 (type: FlowError, retryable: false): There was an error while retrieving the result for pipeline 121199058

@github-merge-queue github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp: database Database Monitoring tag: ai generated Largely based on code generated by an AI or LLM tag: no release notes Changes to exclude from release notes tag: performance Performance related changes type: refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants