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

🚦 14 Pipeline jobs failed

DataDog/java-profiler | benchmarks-candidate-aarch64: [alloc]     

DataDog/java-profiler | benchmarks-candidate-aarch64: [cpu,wall,alloc,memleak]     

DataDog/java-profiler | benchmarks-candidate-aarch64: [cpu,wall]     

View all 14 failed jobs.

Useful? React with 👍 / 👎

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

[dd-octo-sts]

CI Test Results

Run: #27819097390 | Commit: 53ae346 | Duration: 13m 17s (longest job)

✅ All 32 test jobs passed

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

Summary: Total: 32 | Passed: 32 | Failed: 0

---

Updated: 2026-06-19 10:18:21 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...