feat(profiler): wall-clock signal suppression for idle threads

[kaahos]

What does this PR do?:

Before sending SIGVTALRM, the wall-clock timer checks whether the target thread is already in a skippable OS state and has already produced a sample during this blocking run. If so, the signal is suppressed. The first sample of every blocking run is always collected.

Motivation:

High-frequency wall-clock sampling on threads spending most of their time idle generates many redundant samples of identical stacks at high CPU cost. The precheck lets us emit one representative sample per blocking run and skip the rest, recovering signal throughput for threads that are actually running.

This is the first of two PRs splitting paul.fournillon/wallclock_precheck. This PR ships the suppression infrastructure. The follow-up PR adds datadog.TaskBlock event recording.

Additional Notes:

How to test the change?:

New unit tests:

• ddprof-lib/src/test/cpp/park_state_ut.cpp
• ddprof-lib/src/test/cpp/wallprecheck_args_ut.cpp

New integration tests:

• PrecheckTest: verifies suppression fires and reduces signal count.
• PrecheckEfficiencyTest: measures overhead reduction under sustained park.
• WallclockMitigationsCombinedTest: end-to-end combined mitigations scenario.

Run locally with:
./gradlew :ddprof-test:test --tests '*Precheck*' --tests '*WallclockMitigations*' --tests '*WallclockTimer*'

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.
• JIRA: [JIRA-14354]

Unsure? Have a question? Request a review!

[datadog-prod-us1-5]

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 31 Pipeline jobs failed

DataDog/java-profiler | reliability-chaos-aarch64: [profiler+tracer, gmalloc, 25.0.3-tem]     

DataDog/java-profiler | reliability-chaos-aarch64: [profiler+tracer, tcmalloc, 21.0.3-tem]     

DataDog/java-profiler | reliability-chaos-aarch64: [profiler, gmalloc, 21.0.3-tem]     

View all 31 failed jobs.

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3bfa844 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

CI Test Results

Run: #28039576970 | Commit: 5835d1c | Duration: 13m 21s (longest job)

❌ 5 of 32 test jobs failed

Status Overview

JDK	glibc-aarch64/debug	glibc-amd64/debug	musl-aarch64/debug	musl-amd64/debug
8	-	✅	-	-
8-ibm	-	✅	-	-
8-j9	✅	✅	-	-
8-librca	-	-	❌	✅
8-orcl	-	✅	-	-
11	-	✅	-	-
11-j9	✅	✅	-	-
11-librca	-	-	❌	✅
17	✅	✅	-	-
17-graal	✅	✅	-	-
17-j9	✅	✅	-	-
17-librca	-	-	❌	✅
21	✅	✅	-	-
21-graal	✅	✅	-	-
21-librca	-	-	❌	✅
25	✅	✅	-	-
25-graal	✅	✅	-	-
25-librca	-	-	❌	✅

Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled

Failed Tests

musl-aarch64/debug / 25-librca

Job: View logs

No detailed failure information available. Check the job logs.

musl-aarch64/debug / 21-librca

Job: View logs

No detailed failure information available. Check the job logs.

musl-aarch64/debug / 11-librca

Job: View logs

No detailed failure information available. Check the job logs.

musl-aarch64/debug / 17-librca

Job: View logs

No detailed failure information available. Check the job logs.

musl-aarch64/debug / 8-librca

Job: View logs

No detailed failure information available. Check the job logs.

Summary: Total: 32 | Passed: 27 | Failed: 5

---

Updated: 2026-06-23 16:46:50 UTC

[kaahos]

@copilot review this PR

[Copilot]

@copilot review this PR

Reviewed the changes; no blocking issues found in the wall-clock precheck logic or tests.

[jbachorik]

[Sphinx Review — HIGH · CONSENSUS] wallClock.cpp · WallClockJvmti::timerLoop · completeness

WallClockJvmti::timerLoop() and signalHandler() have no wallprecheck logic. WallClockJvmti::initialize() never reads args._wall_precheck and the class has no _precheck member. When jvmtistacks=true is combined with wallprecheck=true (valid on HotSpot JDK 11+ where canRequestStackTrace() returns true), the precheck suppression feature is silently a no-op — no timer-thread fast-path, no signal-handler suppression, no counter increments.

Suggestion: Either (a) add the same once-per-run precheck logic to WallClockJvmti::timerLoop/signalHandler mirroring the WallClockASGCT path (switching to timerLoopCommon<ThreadEntry> with collect(entries)), or (b) document the incompatibility and emit a warning/error in Profiler::start() when both jvmtistacks and wallprecheck are enabled.

Confirmed by adversary.

[jbachorik]

[Sphinx Review — MEDIUM] thread.h · ProfiledThread park infrastructure · necessity

_park_start_ticks and _park_context are captured on every LockSupport.park call but parkExit0 immediately discards both output values. FLAG_PARKED is set/cleared but never consulted in any production path. setJavaThread was made more expensive (CAS loop) to preserve FLAG_PARKED that nothing reads. The PR description says TaskBlock event recording is in PR2.

Suggestion: Either strip _park_start_ticks, _park_context, and FLAG_PARKED from ProfiledThread until they are consumed in PR2, or add a Jira ticket reference linking this scaffolding to the follow-on work. If kept, revert setJavaThread to the simpler non-CAS form until there is a real reader for FLAG_PARKED.

[jbachorik]

[Sphinx Review — LOW · CONSENSUS] thread.h · setJavaThread comment · consistency

The comment justifying the CAS RMW states parkEnter/parkExit run "in signal-handler context" but they are JNI calls from Java application threads, not signal handlers. The concurrent access that justifies the CAS is between the owner thread calling parkEnter/parkExit (JNI) and a different thread calling setJavaThread (JVMTI onThreadStart or vmStructs).

Suggestion: Replace with: "CAS RMW to update only TYPE_MASK bits without clobbering FLAG_PARKED, which may be written concurrently by parkEnter/parkExit JNI calls on the owner thread while a JVMTI callback modifies thread type on a different thread."

[kaahos]

@copilot review this PR.

[kaahos]

most of the previous comments have been addressed @jbachorik! The branch now also includes the new features coming from main.

[rkennke]

This is a nice improvement! I have some questions...

[rkennke]

Two follow-up accuracy/design questions on the weighted-sampling logic (not blockers). Thanks for addressing all my earlier points thoroughly.

[rkennke]

Unowned path: the accumulated tail weight is discarded on a blocked→runnable transition.

shouldRecordUnownedBlockedSample() accumulates unowned_blocked_pending_weight for each suppressed signal, but that pending weight is only flushed into a real sample when the next record-decision fires (decision % kUnownedBlockedFallbackRatio == 1). When the thread goes runnable, this else branch calls resetUnownedBlockedSampling(), which zeroes the pending weight — so the suppressed intervals since the last recorded sample are dropped rather than attributed.

Concretely, at wall=1ms a ~9ms unowned block that ends before the 11th signal emits exactly one sample of weight 1, undercounting it ~9×. The "first sample of every run" guarantee still holds, but total blocked-time accounting is systematically under-reported for short/medium unowned blocks (the only production-active path, since precheck is opt-in).

Is this approximation intended? Would it be more accurate to flush the pending weight into the last sample (or emit a final weighted sample) on the runnable transition instead of discarding it?

[kaahos]

that's a good catch, thanks. I fixed this by preserving the last recorded unowned blocked stack and flushing the accumulated pending tail weight when the thread transitions back to runnable, instead of dropping it in resetUnownedBlockedSampling(). addressed in 5e484d0.

[rkennke]

Owned path: no weight compensation for suppressed signals.

Unlike the unowned path, the owned-block branch emits one sample of weight 1 and then fully suppresses every subsequent signal for the run with no accumulated weight. So a long instrumented sleep/park is attributed only a single interval of wall time, and the rest of the blocked duration is lost from the wall-clock view — presumably to be recovered by PR2's datadog.TaskBlock event.

This is safe in this PR because the only callers of parkEnter/blockEnter are tests. Could you confirm the owned hooks won't be enabled on any production/tracer path before PR2 lands? Otherwise instrumented blocks would undercount wall time in the interim.

[kaahos]

I confirm, in this PR the owned hooks are not wired to production/tracer instrumentation; the only current callers are tests.

To make that harder to misuse before PR2, I made the Java wrappers package-private and moved test access behind a test-only ProfilerOwnedBlockHooks bridge. The native entry points remain private, and PR2 will be where production TaskBlock instrumentation is introduced. addressed in 3bfa844.