arena: the idle pull-forward uses the CAS paths, and a two arena test for the purge schedule

[robobun]

Follow-up to #39 from a review after its merge.

Problem

• _mi_arenas_purge_now (src/arena.c) pulls an arena expire forward with a load and a store, and does the same for subproc->purge_expire. A purge pass resets both. A store that lands after the reset arms an arena that the pass just handled.
• In the worst case an arena is armed and the subprocess is not, until the scavenger's 30 s look at the arenas. It needs a thread preempted between its load and its store for a whole pass: a hardening, nothing was seen.
• test-purge-behind-pass covers one arena. With two, a pass that only fixes all_visited still loses a free into an arena that the pass has left, and the test does not see it.

Fix

• The arena expire moves with a CAS from the value read. The subprocess expire goes through mi_subproc_schedule_purge, as in a pass.
• New test part: both arenas get a batch, then one more block goes into the main arena while the pass is in the other.
• Verified: the new part fails on 8565de2 plus the one line all_visited fix (258 of 264 MiB, 3 of 3 runs) and passes here. Full ctest passes.

Background

• arena->purge_expire is when an arena is due. A free arms it (sets it from 0). subproc->purge_expire is the earliest of these. The scavenger sleeps until then.
• A pass resets subproc->purge_expire first and puts back the earliest arena expire still pending at its end (arena: what is freed during a purge pass is purged by the next pass #39).
• _mi_arenas_purge_now runs when a thread goes idle. It makes every scheduled purge due at once.

Notes

The third part needs no thread of its own. arena_purges counts the arenas a pass went into, so the test waits for it to move by two (the main arena first, then the arena of the test) and frees the last block then. If the pass is over by then, the free takes the normal path and the part passes as well, so it cannot fail on a build that has the fix.

The reservation for the test arena is four times what goes into it. A block of 8 MiB and a bit starts on a boundary in an arena: three share 32 MiB on a 64-bit target, and each one takes 32 MiB on a 32-bit one. The first push reserved less, and the part failed with out of memory in the Win32 Debug jobs (3 of the 4 blocks fit). An arena that still does not take all of the blocks ends the part with a message and does not fail it. On Win32 (Debug and Release, MSVC) the part now runs and ends with 72 of 72 MiB.

With MI_TSAN or MI_TEST_LIGHT the first part runs two rounds and the third part uses a quarter of the blocks. That is less memory traffic in total than the test had before the third part, so the thread sanitizer job has no more to do per test than before. The first push was red there as well. I cannot read the job logs from where I work, so I do not know which test it was. A Debug build spends 20 s in this test (17 s of it in the kernel), which makes the per test time limit my first suspect. The smaller part still fails on the one line all_visited fix (129 of 136 MiB, 2 of 3 runs).

Not done, and why. The review also proposed a debug check under the purge guard that an armed arena implies an armed subprocess. A free arms the arena first and the subprocess second, so the check can see the state between the two and fail without a defect.

Local runs on Linux x64: Release 31 of 31, Debug (MI_DEBUG_FULL) 32 of 32. The purge, park and fork tests also pass with ASAN, MI_GUARDED, MI_SECURE and MI_USE_CXX. My stress harness (8 busy threads, pause without a park): 0 stuck rounds of 230.

No pin bump in bun is needed for this by itself. It can ride with the next one.