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

For the switch port, we had to solve many of the same issues with safepoints and arm64 in an even more restricted environment. For scanning the register context, I had a different solution where hitting a safepoint called a trampoline to spill all its registers to avoid relying on signals and interrupt contexts. (basically, I got gc working reliably with no hardware interrupts on arm64).
The code is on my fork of sbcl on github under the name elfinate-arm64 under the feature flag #+no-os-protect, which also has some cas code to do the software foreign safepoint implementation. It works rather robustly and may be of some interest for the Windows port.
I don’t think we passed the concurrent hash table test either, but in practice it didn’t seem to cause issues in real code and I don’t think it’s really a show stopper for merging a port for sure. It’d be nice to have a proper fix.
The explanations seem like they could have been AI-hallucinated, so I’d like to have a disclaimer from Masatoshi if that’s the case to save on some confusion. I know the code is already disclaimed to be co-authored by an LLM, but it’s helpful to know what is a human-confident diagnosis vs an LLM-confident diagnoses.
On Friday, February 13, 2026, 6:32 PM, Stas Boukarev <[email protected]> wrote:

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

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