Wire -Pjmh.includes and -PtestJvm into internal-api JMH config#11703
Conversation
Without this, -Pjmh.includes is silently ignored by the me.champeau.jmh plugin, requiring a full fat-jar build to run a single benchmark. -PtestJvm was also ignored for JMH execution, defaulting to the Gradle daemon JVM regardless of the requested version. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Hi! 👋 Thanks for your pull request! 🎉 To help us review it, please make sure to:
If you need help, please check our contributing guidelines. |
This comment has been minimized.
This comment has been minimized.
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
The internal-api/build.gradle.kts -Pjmh.includes / -PtestJvm wiring belongs in its dedicated PR (#11703), not here. Revert it so this PR is just the benchmark. Also correct the results header to "MacBook M1 Pro Max". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Align TagMapAccessBenchmark with UnsynchronizedMapBenchmark at @fork(2) for steadier numbers (results to be refreshed on the next run). Also revert the internal-api/build.gradle.kts -Pjmh.includes / -PtestJvm wiring, which belongs in its dedicated PR (#11703), not here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Atomics benchmark Benchmark to show cost of Atomic vs AtomicFieldUpdater Merge branch 'master' into dougqh/atomics-benchmark spotless Merge branch 'master' into dougqh/atomics-benchmark Update internal-api/src/jmh/java/datadog/trace/util/AtomicsBenchmark.java Co-authored-by: Sarah Chen <sarah.chen@datadoghq.com> Fix data race in AtomicsBenchmark scaffolding index sharedLookupIndex was a plain static int incremented by all 8 JMH threads without synchronization — a data race that could cause contention measurements to reflect arbitrary holder access patterns. Move index to @State(Scope.Thread) so each thread has its own cursor. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Wire -Pjmh.includes and -PtestJvm into internal-api JMH config Without this, -Pjmh.includes is silently ignored by the me.champeau.jmh plugin, requiring a full fat-jar build to run a single benchmark. -PtestJvm was also ignored for JMH execution, defaulting to the Gradle daemon JVM regardless of the requested version. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Update AtomicsBenchmark results with corrected Java 17 numbers Re-run after fixing the shared-index data race. The incrementAndGet results increased dramatically (~16M → ~91-121M ops/s) because the prior run was measuring contention on the shared index rather than the atomics themselves. Notable: atomic_incrementAndGet (121M) now outperforms atomicFieldUpdater_incrementAndGet (91M) for the increment op; the AFU advantage is in construction (2215M vs 1872M, saving 16 B/op). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Clarify AtomicsBenchmark recommendation: tradeoff depends on access pattern AFU wins on construction (16 B vs 32 B/op); AtomicInteger wins on incrementAndGet (~33% faster). Updated Javadoc to present both sides rather than a blanket recommendation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Add VarHandle note to AtomicsBenchmark Javadoc VarHandle (Java 9+) is the modern replacement for AtomicIntegerFieldUpdater and would likely close the incrementAndGet performance gap. Not usable here because internal-api targets Java 8. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Merge branch 'master' into dougqh/atomics-benchmark Drop JMH gradle wiring from atomics PR; fix results header machine name The internal-api/build.gradle.kts -Pjmh.includes / -PtestJvm wiring belongs in its dedicated PR (#11703), not here. Revert it so this PR is just the benchmark. Also correct the results header to "MacBook M1 Pro Max". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: devflow.devflow-routing-intake <devflow.devflow-routing-intake@kubernetes.us1.ddbuild.io>
What This Does
Wires two previously-ignored Gradle properties into the
internal-apiJMH configuration:-Pjmh.includes=<pattern>— filters which benchmarks run. Previously silently ignored by theme.champeau.jmhplugin, requiring a full fat-jar build to run a single benchmark.-PtestJvm=<version>— selects the JVM used for benchmark execution. Previously ignored, defaulting to whatever JVM the Gradle daemon happened to use.Usage:
Motivation
Running a single benchmark without this fix required building the full fat-jar and invoking it manually. The JVM defaulted to the daemon JVM rather than the requested version, making results non-reproducible across machines.
Additional Notes
The same pattern applies to other modules that use
me.champeau.jmh(there are ~10 others). This PR fixesinternal-apiwhere current benchmark development is happening; other modules can adopt the pattern as needed.tag: no release note🤖 Generated with Claude Code