Re: [Sbcl-commits] master: Add defensive GC validation for concurrent hash table operations on ARM64
Stas Boukarev <[email protected]> Fri, 13 Feb 2026 18:11:17 +0300
| Newsgroups | gmane.lisp.steel-bank.devel |
|---|---|
| Message-ID | <CAF63=13HNZR4bv04TE+4XWKokLrx2BoBB0=W8JVG6QBktfDn-g@mail.gmail.com> |
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