tests: make weak-table weakness tests robust under conservative GC

[dg1sbg]

Fixes #1814.

WEAK-KEY-AND-VALUE-WEAKNESS fails intermittently on clasp/ubuntu-latest/bytecode. The identical commit failed the regression step on one run and passed it on another, while macos/bytecode and ubuntu/native passed both times — so it is non-deterministic, not a real regression. Details and run links in #1814.

Why the tests are fragile

All four weakness tests share this shape:

(let ((table (make-hash-table :weakness :key-and-value)))
  (setf (gethash (list nil) table) :value
        ...)
  (gctools:garbage-collect)
  (hash-table-count table))

Two things make that unreliable under Boehm's conservative stack scanning:

1. The throwaway (list nil) values are created in the same frame that then calls garbage-collect, so their addresses are still sitting in live stack slots and registers when the collector scans the stack. The collector cannot tell those words from real references and keeps the entries alive.
2. A single collection is assumed to be enough.

Either one leaves a dead entry alive and the count comes out one too high. Because it depends on register allocation and stack residue, it can be perturbed by entirely unrelated codegen changes elsewhere in the tree — which is how it surfaced.

The existing comment already acknowledged these are "pretty strict"; this makes them strict about the property being tested rather than about incidental stack layout.

Change

• Populate the table in a builder function that returns before the collection, so the frame holding the temporaries is popped and below the stack pointer when the scan happens.
• Collect up to TRIES times rather than exactly once.
• One WEAK-COUNT helper shared by all four tests instead of repeating the retry logic four times.

Not vacuous

A retry loop risks turning the test into a tautology, so I checked that it still fails on genuine retention. Holding one key in a global:

dead temporaries      => 1   (expected 1, passes)
one key held globally => 2   (expected 1, still fails after all attempts)

An entry that is really retained never reaches the expected count, so the tests keep their teeth.

Verification

macOS arm64, boehmprecise: full suite 1979 successes, zero unexpected failures; the weakness tests pass 3/3 across repeated TEST_SUITES=hash-tables0 runs. (weak-key-or-value-weakness is #-use-boehm and does not run on these variants, but is updated for consistency.)

[dg1sbg]

Tried to validate this on Linux, where the flake actually occurs. The result is inconclusive, and I would rather say so than imply the fix is proven.

Setup: x86-64 Ubuntu 24.04, LLVM 18, --build-mode=bytecode --no-default-native — i.e. the same configuration as the clasp/ubuntu-latest/bytecode/no/no job that failed twice on WEAK-KEY-AND-VALUE-WEAKNESS. Two arms, same machine, same binary, differing only in which version of hash-tables0.lisp the harness compiles at run time:

arm	runs	WEAK-* failures
with this fix	6	0
with this fix reverted (control)	6	0

The control passed too. So this box never reproduced the flake, and the six green runs on the fixed side establish nothing about the fix. Reproduction likely needs CI's environment — 2-4 core runners under memory pressure have a very different stack and heap profile than the 16-core / 157 GB box I used, and conservative-GC retention is exactly the sort of thing that depends on that.

What is established, independent of reproduction:

• The hazard is real. The dead (list nil) temporaries are created in the same frame that then calls garbage-collect, so their addresses are still in live stack slots when the collector scans. Building them in a function that returns first puts that frame below the stack pointer.
• The change does not make the tests vacuous. Holding one key in a global keeps the count at 2 through every retry, so genuine retention still fails.
• No regression: full suites pass on macOS arm64 / LLVM 22 / native (1979 successes, 0 unexpected failures) and on x86-64 Linux / LLVM 18 / bytecode (1979, 0 unexpected failures, 13 consecutive runs).

So this rests on the reasoning plus the non-vacuity check, not on an observed before/after. If the flake reappears after this merges, that is the reason.

[Bike]

For the moment I'm just going to mark the tests as known failures under Boehm. Boehm is not reliable enough for us to be able to mandate that objects are collectable.