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

Alright, I put some brain joules into it, and things look better. All
the wild goose chase for gethash-concurrency was caused by
scrub-control-stack declining to scrub due to incorrect stack guard
pages direction.
More fails to be addressed.

On Fri, Feb 13, 2026 at 4:57 PM Christophe Rhodes via Sbcl-devel
<[email protected]> wrote:
>
> 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
>
>
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel