The thirds approach (comparing earliest third vs recent third of the
ring) only uses 2/3 of the data and is noisy for
oscillating-but-growing trends. A klass that grows
steadily over 30+ GC epochs but oscillates within each
30-sample window can show a negative third-vs-third
slope even though the overall trend is clearly up.

Replace ringThirdsStats with a full-window least-squares
linear regression (y = a + b*x, x = sample position 0..fill-1).
This uses all samples and produces a proper slope
that matches what a dashboard graph shows.

Updated SecondsToOOMTest.RisingFloorProjectsExpectedSeconds:
time_delta changed from 7s (thirds: 8-1) to 9s (full window: 9-0).
Expected secondsToOOM changed from 10.0 to 9.0.

Add TEST_LOG to:
- recordHeapFloorSample: logs used bytes + timestamp for each sample
- onGC: logs when heap floor is recorded + GC epoch
- secondsToOOM: logs ring fill, bytes_delta, time_delta, means,
  and why it returns -1 (insufficient fill, not rising, etc.)
- heapFloorRising: logs mean/floor values + why it returns false
- selectLeakCandidates: logs summary (candidate count, required hysteresis,
  heapFloorRising state)
- hasLeakSignal: logs final verdict (secondsToOOM + candidates)

This gives full visibility into why the leak detector
isn't firing, in one deployment.

…or ring

The heap floor ring shows fill=0 despite onGC recording a sample.
Added TEST_LOG to recordHeapFloorSample to see whether it's
entered and whether _heap_floor_recording_disabled_for_test
is incorrectly true on the hotdog.

On JDK 26 with generational ZGC, _used_at_last_gc (read
from CollectedHeap via VMStructs) reports the committed
heap size, not the used bytes. The heap floor
would appear flat (7.5GB constant) even as the real
used bytes grow (2.19GB and rising).

Fix: in resolvePostGcHeapUsage(), when UseZGC is
enabled and hotspot_version >= 26, fall back to
HeapUsage::get(false)._used (the JMX path) instead of
_used_at_last_gc. Scoped to ZGC on JDK 26+ only —
other GC/JDK combinations keep the existing
_used_at_last_gc path.

VMFlag::find is a VMStructs table walk — don't call it on
every GC. Cache the result (UseZGC && hotspot_version >= 26)
as _is_zgc_jdk26_plus in initialize(), read it in
resolvePostGcHeapUsage().

LEAK_GROWTH_ABS_MIN was 5 (minimum 5 instances/epoch slope).
For large-population klasses (e.g. byte[] with thousands of
instances), a slope of 0.5 instances/epoch is
significant (~5% growth) but far below 5. The absolute
floor of 5 was too high, rejecting real leaks
in large-population klasses.

Lowered to 1 so only klasses with very small populations
(< 7 instances) need an absolute floor. This still
rejects single-instance oscillation noise while allowing
real leaks in large-population klasses.

Also: cache ZGC JDK26+ check in initialize() with debug logging.

…n't pre-tagged

selectLeakCandidates() was reading cached_slope directly without calling
hasQualifyingGrowth(), so consecutive_positive was not
updated for the current scan. The cached_slope could be stale
(set by a previous push with a negative slope), causing
selectLeakCandidates to skip the klass even though the
current trend is positive.

Fix: call hasQualifyingGrowth(entry) in selectLeakCandidates()
so consecutive_positive is updated and the slope is fresh.
Made hasQualifyingGrowth() take const ref (cached_slope is mutable).

Instead of pre-tagging candidate objects with negative marker tags
(MARKER_TAG_BASE - i), match by class_tag in heapReferenceCallback().
This avoids SetTag entirely: the walk visits every object
normally, and when it encounters one whose class matches
a candidate klass ID, it records the chain link and
skips expanding that object's children.

- _candidate_tags[i] now holds the klass ID (not marker tag)
- _candidate_frontier_tags[i] holds the frontier tag assigned
  by nextTag() when pruning
- buildCanaryChainEvent() uses _candidate_frontier_tags[i] as
  both the frontier table key and the target_tag
- pollWatchedTargets() canary path checks tag > 0 (frontier tag from
  heapReferenceCallback) instead of tag <= MARKER_TAG_BASE

Tests need updating: PollWatchedTargetsTest expects the old
marker-tag approach. 3 tests fail.

Tests now set _candidate_frontier_tags via
setCandidateFrontierTagForTest() so
buildCanaryChainEvent() can reconstruct the chain.
Added setCandidateFrontierTagForTest() test accessor.

… shouldRunPass

MIN_EFFECTIVE_BUDGET was 50, which the PID controller used as a
floor when throttling. For canary search, 50 edges/pass is too
low — the walk never reaches deep candidates.

Raised to 500 so the PID controller can let each pass explore more
edges while still bounding STW pause.

Also moved the cadence sleep to after shouldRunPass() so
passes run back-to-back when canary search is active
(no sleep when a pass is about to run).

Updated PacingGrowsBudgetBackAndRelaxesCadenceWhenUnderCeiling test
to use setEffectiveBudget(600) (above the new floor).

Canary-matched candidates were never getting a JVMTI tag set, so
buildCanaryChainEvent() could never see them as found. Also add a
TEST_LOG line to trace klass_id -> class name resolution.

resolveClassMap only logs a class the first time it's tagged, so a
class already loaded before referenceChains' own scan first ran never
gets logged. Resolve the name live off the candidate's representative
object in pollWatchedTargets instead.

Class-tag matching let heapReferenceCallback record a chain for any
instance of a candidate's class, not the specific representative
LivenessTracker flagged as growing - for common classes (e.g. byte[])
this meant the recorded chain almost never belonged to the actual leak.
Revert to pre-tagging each candidate's representative with a distinct
marker tag and matching by identity.

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

Update pacing tests' configured budget/iteration count to match.

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

…ents

Integer division in autoTuneDefaults() truncated the budget-to-cap ratio,
undershooting the frontier cap. Comments describing FRONTIER_CAP_HIT as
abandoning the search outright didn't match runPass()'s actual behavior.

Compares the JVM heap limit against the container/cgroup memory limit
(unavailable treated as unbounded) and runs the trend extrapolation once
against whichever boundary is tighter, so container-memory-driven OOM
kills are projected even when heap occupancy alone looks safe.

…udget for non-safepoint pass cost

Split pass timing into safepoint_ticks (real JVMTI/FollowReferences duration,
fed to updatePacing()) and non_safepoint_ticks (bookkeeping/dispatch,
spent into a new independent _cpu_pain_budget gating shouldRunPass()).
Renamed _pain_budget to _safepoint_pain_budget for clarity.

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

…ling forever

Once the frontier table saturates, no new entries can ever be admitted,
so the no-progress detector can never actually fire -- the frontier-cap
branch matched every subsequent pass, permanently blocking abandonment.

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

Replaces the binary 5ms/50ms pause-target step with a continuous
exponential ramp (5ms->100ms, cadence 1s->10ms) as secondsToOOM() falls
within OOM_RAMP_START_S, so the search spends progressively more STW
budget the closer the app gets to dying. Budget bump is held for the
whole ramp window rather than a one-shot at the old threshold.

OOM_RAMP_START_S is temporarily set to 6000s (100 min, TESTING ONLY) to
observe ramp behavior live in the hotdog pod; must be reverted to 1800.0
before merging.

Guards against a one-time step change (e.g. cache prefill) that
plateaus immediately: the full-window regression alone stays "rising"
until the step's samples age out of the ring, but a second fit over
just the most recent half collapses to flat as soon as growth stops.

cadence_ns was only used for the loop's own sleep calls and never written
back to _effective_cadence_ns, so shouldRunPass()'s cadence gate stayed
pinned at the 1s baseline during urgency instead of ramping down.

Without it, the sweep always rescanned from tag 1, so a large permanent
population of low-tag EXPANDED entries could fill its per-pass cap forever,
starving any higher-tag entry (e.g. a static field's collection admitted
after startup) from ever being re-queued.

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

…latch, completion gating, generation sync

Rediscovering new elements in an already-discovered static-field
collection was failing end-to-end. Root causes fixed together
(verified via ExternalProcessReferenceChainTest):

- classMap dictionary-id instability -> shared ClassTagAllocator with
  stable class_tag matching, replacing referrer_klass
- klassPopulationSetRepresentativeForTest() test seam bypassed stable
  class-tag minting -> routed through mintStableClassTagIfNeeded()
- isUrgent()/hasLeakSignal() flapped near the OOM threshold, causing
  a search restart almost every tick -> latch + release hysteresis
- runPass() could reach terminal SearchState::COMPLETED while a leak
  klass was still watched -> gated on _watched_leak_klass_count == 0
- LivenessTracker::_last_class_map_generation wasn't synced in
  initialize(), spuriously wiping _klass_population on the first
  cleanup_table() call -> synced to the real classMap generation

Also reverts OOM_RAMP_START_S from its temporary 6000.0 (100 min,
used to observe ramp behavior live) back to the production 1800.0
(30 min).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Adds Component 4 to the reference-chains design summary, describing
the growing-collection fix set from 209336e.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…rgent-independent stuck detector

pollWatchedTargets() indexed candidate arrays by loop position instead of
the tag-decoded slot, so canary chains were never resolved. Pre-tagging
was also one-shot, letting the tracked candidate set desync from
selectLeakCandidates(). Additionally add a canary-specific no-progress
abandon path that isn't suppressed by isUrgent(), so a livelocked urgent
search can still terminate.

…ount

Queue abandoned-search events at the moment of abandon so dump() no longer
races restartSearch()'s state reset. Escalate the non-safepoint pain budget
while a canary search has unresolved candidates, and drop a leftover
unconditional sleep in threadLoop() that blocked back-to-back canary passes.

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