Fix tryClaim busy-looping on a slot held through a thread-local cache

[soerenreichardt]

Problem

tryClaim() can fail to return while another thread holds an object it claimed through its thread-local cache. While it spins, it allocates without bound. We hit this in production: a pool of 4 objects shared by 8 threads drove a 30 GB JVM into back-to-back full GCs within seconds.

Root cause

BlazePool.slowClaim(BSlotCache) only polls the live-queue when its local slot is null:

slot = newAllocations.pop();
for (;;) {
  if (slot == null) {
    slot = live.poll();
  }
  if (slot == null) {
    disregardPile.refill();
    return null;
  } else if (slot.live2claim()) {
    ...
  } else {
    disregardPile.push(slot);   // slot is not reset
  }
}

A slot claimed through the thread-local fast path (tlrClaim, live2claimTlr) is not removed from the live-queue. It sits there in the TLR_CLAIMED state. Each pass of the loop then does the following:

1. live.poll() returns that slot.
2. live2claim() fails, because the state is TLR_CLAIMED, not LIVING.
3. The slot is pushed onto the disregard pile. That allocates a RefillSlot, which stays reachable from the pile.
4. slot is still non-null, so the next pass skips the poll and retries the same slot.

The loop only exits once the holder calls release() and the CAS finally succeeds. Until then, tryClaim() behaves like an unbounded blocking claim that also leaks memory. The next refill() then calls live.offer once per pushed node. The live-queue fills with duplicates of the same slot, and later claims have to drain them.

The timed slowClaim(Timeout, BSlotCache) doesn't have this problem. It reassigns slot from newAllocations.pop() or live.poll(...) at the top of every pass, and it is bounded by the timeout. So claim(new Timeout(0, ...)) returns null immediately in the same situation, while tryClaim() hangs.

Fix

Set slot = null at the end of each pass, so every pass polls the live-queue, matching the timed variant.

🤖 Generated with Claude Code

[chrisvest]

Created https://codeberg.org/chrisvest/stormpot/issues/21 to track