Add java_cpu_alloc scenario for the Datadog java-profiler - #155
Add java_cpu_alloc scenario for the Datadog java-profiler#155jbachorik wants to merge 7 commits into
Conversation
Builds jfr2pprof from source, runs the profiler agent against a deterministic cpu/alloc workload, and converts the recording via the datadog.yaml mapping to validate cpu-samples and alloc-samples.
Makes the workload's purpose explicit and avoids the sole fully-qualified name (LockSupport) in favor of a proper import.
Matches the other prof-correctness profilers (ddprof's latest-rc tag, dd-trace-py/-rb/-js's unpinned/master dependencies), which default to latest and only pin a specific build as an explicit override.
Drops the from-source Gradle build stage now that jfr2pprof ships inside jafar-tools, resolvable via jbang.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dbb7d0b120
ℹ️ 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".
| # jfr2pprof has no --help; running it bare still resolves/caches the jbang | ||
| # dependency, it just exits non-zero after printing its usage string. | ||
| RUN jbang trust add https://github.com/btraceio/ \ | ||
| && (jbang jafar-tools-latest@btraceio jfr2pprof || true) \ |
There was a problem hiding this comment.
When the JBang warm-up fails for anything other than the expected no-args usage exit (for example a catalog/Maven resolution error, alias change, or trust prompt), || true still lets the Docker image build as if jfr2pprof were cached. The scenario then fails later in run.sh when it needs the uncached tool, which makes the build-time caching guarantee unreliable; make this step distinguish the expected usage exit from dependency-resolution failures.
Useful? React with 👍 / 👎.
kaahos
left a comment
kaahos
left a comment
There was a problem hiding this comment.
it looks good to me, thanks!
I would just recommend maybe adding a short README describing the test to match the architecture of the other scenarios and also adding the scenario to the CI?
java:
uses: ./.github/workflows/test.yml
with:
test_scenarios: java.*
secrets: inherit
|
Alternative approach : https://github.com/DataDog/prof-correctness/pull/156/changes |
|
@r1viollet did you do completeness check on that jfr parser in go? Also, I would rather stick with the devil I know - we are using the jafar parser in other parts, it is a complete JFR parser, very well tested and with extraordinary performance. I thought the reason to use the go JFR parser was to do more by-event comparisons, but since the result is again pprof files the difference to converting jfr to pprof by those two tools is almost none? |
4 participants
Summary
scenarios/java_cpu_alloc/, the firstprof-correctnessscenario for the Datadog java-profiler (PROF-15290).jfr2pprof(btraceio/jafar, pinned to thev0.26.1release) from source, downloads the java-profiler native agent (v1.45.0) from its GitHub release, compiles a small deterministic workload, runs it under the agent to record a.jfr, then converts it to pprof viajfr2pprof --config datadog.yaml.datadog.yaml, the jfr2pprof mapping for the Datadog java-profiler's JFR events (datadog.ExecutionSample,datadog.MethodSample,datadog.ObjectSample,datadog.HeapLiveObject), coveringcpu-time,wall-time,allocation, andlive-heap.CpuBurner(busy-spins, dominates CPU samples) andAllocGenerator(batches allocations with a park, dominates allocation samples), soexpected_profile.jsoncan assert distinct, non-overlapping method-qualified folded stacks per thread.cpu-samples/alloc-samplesare asserted here;wall-timeandlive-heapare mapped but not exercised by this workload (see caveats documented indatadog.yaml).While building this, found and reported a real
jfr2pprofbug (frame.format was parsed but never applied toFunction.Name, collapsing all frames of a class into one node) — filed as btraceio/jafar#105 and fixed upstream inv0.26.1, which this scenario is pinned to.Test plan
TEST_SCENARIOS="java_cpu_alloc" TEST_RUN_SECS=10 go test -v -run TestScenarios ./...passes locally: bothcpu-samplesandalloc-samplesassertions succeed at 0% error.