… 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).

Address Roman's review comments:

1. Make _inflight private with accessors (enterHandler/exitHandler/
   hasInflightHandlers). Restore protected access for _interval, _cstack,
   _signal, _max_timers, _timers (subclass CTimerJvmti needs them).

2. Move InflightGuard into ctimer.h as header-only. Removes engine coupling
   from guards module: guards.cpp no longer #ifdef-includes ctimer.h.
   Non-Linux variant is an empty stub class; the _active bool disappears
   since separate class definitions per platform handle the no-op case.

3. Remove dead Profiler::enableEngines() (replaced by explicit
   _cpu_engine->enableEvents(true) / _wall_engine->enableEvents(true)
   in profiler.cpp). disableEngines() is still used and kept.

Three small fixes:

1. ctimer.h: _enabled was moved from protected to private in the previous
   refactor (e7ca730). CTimerJvmti::signalHandler is a subclass member that
   reads _enabled directly, so the symbol must be protected. GCC enforces
   this strictly; clang on macOS did not catch it because the offending
   code is inside #ifdef __linux__. _inflight stays private (only accessed
   via the public enterHandler/exitHandler accessors).

2. ctimer_linux.cpp: remove duplicate #include <time.h> (jbachorik).
   Check clock_gettime() return value in drainInflight(); on failure,
   conservatively report timeout so the caller skips JFR teardown rather
   than spinning against an uninitialized deadline (jbachorik).

3. profiler.cpp: rewrite the wall/CPU enableEvents() comments. The old
   wording claimed wall clock 'doesn't access JFR in signal handlers',
   which is false (both engines write JFR events from signal handlers).
   Correct framing: wall's pthread checks _enabled once at startup and
   exits if false, so it must be enabled before _wall_engine->start();
   CPU handlers re-check _enabled on every signal, so the order vs
   _cpu_engine->start() is incidental (jbachorik).

Address jbachorik review: when drainInflight() times out we previously
proceeded to set _state=IDLE and return Error::OK, leaving the caller free
to call start() against partially-torn-down structures and potentially
deadlocking on _rec_lock if a stuck handler still held it.

Move drainInflight() to immediately after disableEngines(), before any
other engine stop. On timeout, return Error and leave _state at RUNNING:

- caller cannot start() (state guard blocks it)
- caller can retry stop(); disableEngines() is an idempotent atomic store
  and no other engine stop has run yet, so there is no pthread_join double
  invocation hazard from BaseWallClock::stop()
- on retry, if handlers have finally drained, the teardown proceeds for
  the first time and completes normally

Safety of the reorder: after disableEngines() any signal that fires from
now on enters the handler, fails the _enabled check, decrements the
inflight counter and exits without ever touching JFR. So brief
inflight > 0 spikes between drainInflight() returning true and _jfr.stop()
do not race against JFR teardown.

Trade-off: on the timeout path, wall/alloc/native engines keep running
an extra ~200 ms before the caller retries. Acceptable for a pathological
path; the alternative (proceed and deadlock or crash) is worse.