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

Ok, I installed windows arm64 in virtualbox.
The first thing that is broken is C-c
Because FREE_INTERRUPT_CONTEXT_INDEX is not updated:

* (trace sb-di::nth-interrupt-context)
(SB-DI::NTH-INTERRUPT-CONTEXT)
*   0: (SB-DI::NTH-INTERRUPT-CONTEXT -1)
  0: SB-DI::NTH-INTERRUPT-CONTEXT returned
       #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XFFFFFFFFFFFFFFFF :TYPE (*

(SB-ALIEN:STRUCT

 SB-VM::OS-CONTEXT-T-STRUCT))>
C-c
Segmentation fault         ./run-sbcl.sh

And I ran out of time for today.

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