Re: [Sbcl-commits] master: Add defensive GC validation for concurrent hash table operations on ARM64

stassats via Sbcl-commits <[email protected]> writes:

> - Log -----------------------------------------------------------------
> commit 66e8662c13f8a06856222efd7c3159ec6a390a26
> Author: SANO,Masatoshi <[email protected]>
> Date:   Thu Feb 12 13:32:11 2026 +0900
>
>     Add defensive GC validation for concurrent hash table operations
>     on ARM64

I appreciate that this is helpful in getting this platform combination
to a point where it might be useful to some users, but.

>     Root cause: ARM64 weak memory ordering creates a race between mutator
>     threads writing kv-vector entries and updating the high-water-mark
>     (HWM), and the GC thread reading HWM to determine scan range.  The GC
>     may see an old HWM while new entries are already visible, leaving
>     from-space pointers beyond HWM unscavenged.

If this is the case, then all the defensive validation in the world
doesn't give me the confidence in writing (say) a NEWS entry or an
e-mail saying that this port is worth trying.  I would like to see
investigation into: what is the difference between this configuration
and others that exposes the weak memory ordering, and what barriers
might be necessary to make this closer to 100% correct or at least 100%
reliable (rather than 80% as reported in this change).

(This is not a call for a revert, but it would be nice to know whether
this is something that you think you can take on in the near future.)

Thanks,

Christophe