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

Stas Boukarev <[email protected]> Fri, 13 Feb 2026 18:11:17 +0300
Newsgroups gmane.lisp.steel-bank.devel
Message-ID <CAF63=13HNZR4bv04TE+4XWKokLrx2BoBB0=W8JVG6QBktfDn-g@mail.gmail.com>
It builds. The test suite doesn't run (finish).
The loongarch port also has a lot of test failures (some of which I
can't explain and it's probably due to an old kernel).
risc-v is crashing left and right and has a lot of test failures.

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