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

The technical hypotheses in the commit messages — "stale pointers on the
control stack", "concurrent rehash race" — came from LLM-assisted debugging
and turned out to be inaccurate. The crash observations and reproduction
were mine, but the root cause analysis was not solid. I should have been
clearer about the confidence level.

On Sat, Feb 14, 2026 at 7:56 AM Charles Zhang via Sbcl-devel <
[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
>

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