Collect IBM JVM hang dumps with test reports - #12638
Conversation
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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fcb6357586
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
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. |
There was a problem hiding this comment.
|
/merge -f --reason "It is a build change, tested in PR, no need to run MQ" |
|
View all feedbacks in Devflow UI.
The expected merge time in
Warning This change was merged without running any pre merge CI checks Reason: It is a build change, tested in PR, no need to run MQ |
038e0f8
into
master
What Does This Do
Testtask.IBM_JAVACOREDIRto the same task dump directory collected with test reports.kill -3thread dumps and HotSpot-only heap dump suppression.Motivation
When an IBM test task timed out,
kill -3successfully produced a javacore, but the JVM wrote it outside the module dump directory, typically under/tmp. The CI report collector copiesbuild/dumps, so the diagnostic artifact was unavailable after the job.The previous
/ibm8executable-path check was also narrower than the Gradle toolchain configuration and could diverge from the JVM selected for the test task.Additional Notes
Failure evidence from the timeout showed the JVM reporting a successful javacore write under
/tmp/javacore...txt, while no javacore appeared in the collected module reports. The selected launcher is now the single source of truth, andIBM_JAVACOREDIRis inherited by the Gradle test worker and its child processes.Validation:
./gradlew -PrunBuildSrcTests=true :buildSrc:test --tests datadog.gradle.plugin.dump.DumpHangedTestIntegrationTest --rerun-tasks --no-build-cache— 8 tests passed, including a real IBM JVM javacore capture../gradlew :buildSrc:spotlessCheck --no-build-cacheRelevant precedent: #10646 introduced IBM8 thread-dump collection; #12619 established thread-before-heap dump ordering.
OpenJ9 documents
IBM_JAVACOREDIRas the Java dump destination: https://eclipse.dev/openj9/docs/env_var/#java-dump-optionsContributor 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: N/A