Use Java 25 as the default compiler toolchain - #12305
AlexeyKuznetsov-DD wants to merge 3 commits into
Conversation
9760e9c to
7fb66ad
Compare
7fb66ad to
debad44
Compare
|
🎯 Code Coverage (details) 🔗 Commit SHA: 47ba511 | Docs | View more details | Give us feedback! |
Debugger benchmarksParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 9 metrics, 6 unstable metrics. See unchanged results
Request duration reports for reportsgantt
title reports - request duration [CI 0.99] : candidate=None, baseline=None
dateFormat X
axisFormat %s
section baseline
noprobe (356.007 µs) : 335, 377
. : milestone, 356,
basic (339.82 µs) : 332, 347
. : milestone, 340,
loop (8.127 ms) : 8057, 8196
. : milestone, 8127,
section candidate
noprobe (383.998 µs) : 314, 454
. : milestone, 384,
basic (344.054 µs) : 337, 351
. : milestone, 344,
loop (8.124 ms) : 8060, 8188
. : milestone, 8124,
|
🟢 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. |
Kafka / producer-benchmarkParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics. See unchanged results
|
Kafka / consumer-benchmarkParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics. See unchanged results
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
I'll be reviewing this tomorrow morning. |
|
Compared the exact CI artifacts with the repository-pinned
Summary:
Focused jardiff output--- datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.class
+++ datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.class
@@ -48,22 +70,9 @@
- ICONST_3
- ANEWARRAY datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource
- DUP
- ICONST_0
- GETSTATIC datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.ALLOCATE_DIRECT : Ldatadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource;
- AASTORE
- DUP
- ICONST_1
- GETSTATIC datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.MMAP : Ldatadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource;
- AASTORE
- DUP
- ICONST_2
- GETSTATIC datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.JNI : Ldatadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource;
- AASTORE
+ INVOKESTATIC datadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource.$values ()[Ldatadog/trace/bootstrap/instrumentation/jfr/directallocation/DirectAllocationSource;
--- inst/datadog/trace/instrumentation/kafka_clients38/TextMapExtractAdapter.classdata
+++ inst/datadog/trace/instrumentation/kafka_clients38/TextMapExtractAdapter.classdata
@@ -132,9 +132,9 @@
- INVOKEVIRTUAL java/nio/ByteBuffer.flip ()Ljava/nio/ByteBuffer;
+ INVOKEVIRTUAL java/nio/ByteBuffer.flip ()Ljava/nio/Buffer;
--- inst/datadog/trace/instrumentation/springweb6/HandleMatchAdvice.classdata
+++ inst/datadog/trace/instrumentation/springweb6/HandleMatchAdvice.classdata
@@ -53,9 +53,9 @@
- INVOKEVIRTUAL java/lang/Object.getClass ()Ljava/lang/Class;
+ INVOKEINTERFACE jakarta/servlet/http/HttpServletRequest.getClass ()Ljava/lang/Class; (itf)
--- inst/datadog/trace/instrumentation/springweb6/SpringWebHttpServerDecorator.classdata
+++ inst/datadog/trace/instrumentation/springweb6/SpringWebHttpServerDecorator.classdata
@@ -397,9 +404,9 @@
- INVOKEVIRTUAL java/lang/Object.getClass ()Ljava/lang/Class;
+ INVOKEINTERFACE org/springframework/web/servlet/View.getClass ()Ljava/lang/Class; (itf)All affected classes remain Java 8 bytecode:
Spring 6 itself requires Java 17, but that does not change the agent's Java 8 bytecode requirement. I found no additional actionable issue. |
| * @param unsetReleaseFlagReason If not blank, `--release` option will not be applied. | ||
| */ | ||
| def configureCompiler(AbstractCompile it, int toolchainVersion, JavaVersion compatibilityVersion = null, String unsetReleaseFlagReason = null) { | ||
| def configureCompiler(AbstractCompile it, int toolchainVersion, JavaVersion bytecodeVersion, String unsetReleaseFlagReason) { |
There was a problem hiding this comment.
suggestion: I would avoid passing 25 at every call site. It matches the Gradle daemon so in it's somewhat already configured.
I'm thinking about an overload or a default param, where only the bytecodeVersion is needed. Unless, exceptionally, the toolchainVersion is, and when it's not needed use the Gradle Daemon version via JavaLanguageVersion.current()?
This should keep the explicit toolchain version only for JDK 8/11/21 exceptions.
| tasks.named("compileMain_java11Java", JavaCompile) { | ||
| configureCompiler(it, 11, JavaVersion.VERSION_1_8) | ||
| // Do not lift this offset: these JFR bootstrap classes run on Java 8 JFR backports. | ||
| configureCompiler(it, 25, JavaVersion.VERSION_1_8, "Uses jdk.jfr module (Java 11+) at Java 8 bytecode") |
There was a problem hiding this comment.
suggestion: I would avoid repeating the java version if the gradle daemon matches. I.e. make that a default (with the gradle daemon jvm), and use exceptions where needed. See the configureCompiler discussion.
What Does This Do
Uses JDK 25 as the default Java and Groovy compiler toolchain, matching the Gradle daemon JDK. Java compilation whose
toolchain matches the daemon can run in-process instead of starting a compiler JVM for each older module toolchain.
The emitted bytecode version remains explicit and is independent of the compiler JDK. Normal Java compilation uses
--release <bytecodeVersion>. Code that intentionally references newer or unpublished JDK APIs while emitting olderbytecode supplies
unsetReleaseFlagReasonand uses-source/-targetinstead.Toolchain 8, 11, or 21 is retained only where required by compiler or source compatibility, including old Scala compilers,
JDK internals, old Error Prone/NullAway versions, legacy jars, and a JDK 21 preview API removed in JDK 25. Every non-25
selection must include an explanation; Gradle configuration fails otherwise.
This also centralizes the Kotlin DSL
configureCompilerbridge and upgrades the malformed AspectJ 1.8.13 dependency usedby the Zuul instrumentation to 1.8.14 so it can be read by modern
javac.Motivation
Many modules selected JDK 8, 11, 17, or 21 only to control their bytecode level. Because those toolchains differ from the
JDK 25 Gradle daemon, Gradle starts and warms additional compiler JVMs. Using JDK 25 for compilation while preserving each
module's bytecode and API compatibility removes unnecessary process overhead without raising the runtime requirement of
the produced artifacts.
Additional Notes
Local
./gradlew assemble --rerun-tasksbenchmark, with the daemon on JDK 25, one warm-up followed by three measured runs,and the full process tree sampled:
masterA fresh uncached
:instrumentationLatestDepTestprocess-tree comparison with six Gradle workers showed the reduction inJVM creation directly:
master-based baselineThat is about 15-21 fewer JVM forks (19-26%) and 8-9 fewer JVMs at peak. Groovy, Scala/Zinc, tests, and genuine older-JDK
exceptions still fork as required, so this does not eliminate all worker JVMs. Peak memory was effectively unchanged in
the repeated
assemblebenchmark; the demonstrated improvements are fewer processes, lower CPU use, and shorter buildtime.
Validation:
./gradlew assemblemaster; class-file versions were unchanged and differences were limited to expectedcompiler-generated metadata and synthetic representation
JDK 25 is an explicit compiler policy. When the daemon toolchain changes, update this default and its audit guard together.
The benchmark used a warm dependency cache on one machine;
assemblealso includes non-compilation work.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]