… lifecycle

The CPU profiler sends SIGPROF to all threads via per-thread kernel timers.
The signal handler checks _enabled and, if true, calls recordSample() which
accesses JFR buffers. Two races existed around the recording cycle transition
(default every 60 s) where JFR structures could be in mid-init or mid-teardown
while the handler was active:

Race 1 — stop() side (TOCTOU on _enabled vs _jfr.stop()):
  A handler that passed the _enabled=true check could still be executing
  inside recordSample() when disableEngines() set _enabled=false and
  _jfr.stop() freed JFR buffers — use-after-free → SIGSEGV.

  Fix: add an _inflight counter (incremented on handler entry, decremented
  on all exits). CTimer::stop() calls drainInflight() after deleting per-
  thread timers, spinning until _inflight==0 before returning to the caller
  that proceeds to _jfr.stop(). Any handler that fires after disableEngines()
  sees _enabled=false and returns early without touching JFR.

Race 2 — start() side (enableEngines() before _jfr.start()):
  enableEngines() set _enabled=true before _jfr.start() had completed.
  A SIGPROF in that window would see _enabled=true and call recordSample()
  on partially-initialized JFR structures.

  Fix: move enableEngines() to after _jfr.start() and _cpu_engine->start()
  have both returned successfully (just before _state.store(RUNNING)).

Validated empirically: a controlled reproducer in DataDog/profiling-backend
(AnalysisEndpointTest.testResourceExhausted with a 60 s recording period)
showed ~60% failure rate without the fix (SIGSEGV / hang), 0% with both
fixes applied (12/12 iterations clean). Each fix alone only partially
addressed the failures, confirming both races were independently active.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

…iveness

Without a timeout, drainInflight() spins indefinitely if a SIGPROF handler
is stuck (e.g. deadlock inside recordSample()). This would prevent _jfr.stop()
from running and hang JVM shutdown.

Use clock_gettime(CLOCK_MONOTONIC) for a real wall-clock bound of 200ms.
If the deadline fires, log a warning and proceed; in that pathological case
the caller's JFR teardown may race with the stuck handler, but the JVM is
not permanently deadlocked. In normal operation (handlers complete in
microseconds) the timeout is never reached.

Refs: PROF-15201

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

…Guard

Manual increment/decrement of _inflight in signal handlers was error-prone
and led to a counter leak in CTimerJvmti::signalHandler's inInitWindow()
early return path. This would cause drainInflight() to spin for 200ms on
every profiler stop and emit spurious warnings about stuck handlers.

Solution: Add InflightGuard RAII class following the existing pattern in
guards.h (SignalHandlerScope, CriticalSection). The guard increments on
construction and decrements on destruction, making it impossible to forget
the decrement on any exit path.

Benefits:
- Eliminates the entire class of counter-leak bugs
- Makes all exit paths safe by construction
- Follows established patterns in the codebase (SignalHandlerScope)
- Self-documenting: InflightGuard at the start of a handler clearly
  signals its purpose

Changes:
- guards.h: Add InflightGuard class declaration
- guards.cpp: Implement InflightGuard with #ifdef __linux__ (no-op on
  non-Linux where CTimer doesn't exist)
- ctimer_linux.cpp: Replace all manual __atomic_fetch_add/_sub with
  a single InflightGuard declaration at the start of both signal handlers

CI failure revealed _inflight was protected, preventing InflightGuard access.
Also, having _inflight adjacent to _enabled creates false sharing:
- _enabled is read (ACQUIRE) by every signal handler on every thread
- _inflight is written (modify-release) by every signal handler
Sharing a cache line causes unnecessary cache line bouncing.

Solution: Move _inflight to public and align to 64-byte cache line boundary
(alignas(64)). This separates the read-only _enabled hot path from the
read-write _inflight counter, reducing cross-thread traffic.

Note: The counter is still globally updated, but the separate cache line
means _enabled reads no longer compete with _inflight writes.

…use-after-free

Codex P2: The 200ms timeout in drainInflight() previously broke with a warning
but still allowed Profiler::stop() to call _jfr.stop(), recreating the
use-after-free this guard is meant to prevent.

Solution: drainInflight() returns bool; Profiler::stop() skips _jfr.stop() if
timeout fires. This leaks ~few MB but prevents SIGSEGV. Timeout is pathological
(stuck handler), so leak is acceptable. Tested: forcing skip-stop works cleanly.

Normal operation unchanged: _jfr.stop() is called when drain succeeds (<1ms).
Only skips on timeout (200ms expired, handler still in-flight).