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

I see a number of test failures on linux-arm64-sb-safepoint.
But I've never been too trusting of sb-safepoint to bother with them,
especially since now there's :nonstop-foreign-call (I can't proclaim
it to be fully stable)
I've also seen a number of very rare failures without any additional
features (one of which I just fixed, that one goes back to cmucl).
mark-region-gc seems to reliably crash when running concurrent
compilations, but I haven't bothered debugging that.
The point I'm making—nothing's really stable.

On Sat, Feb 14, 2026 at 1:54 AM Charles Zhang <[email protected]> wrote:
>
> 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