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

But yeah, some of these explanations do not make sense.
There can be no stale pointers on the stack. There should be no
concurrent rehash.

On Fri, Feb 13, 2026 at 6:11 PM Stas Boukarev <[email protected]> wrote:
>
> 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