Re: Some experience with the igc branch

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> DEFUN ("function-equal", Ffunction_equal, Sfunction_equal, 2, 2, 0,
>>        doc: /* Return non-nil if F1 and F2 come from the same source.
>> Used to determine if different closures are just different instances of
>> the same lambda expression, or are really unrelated function.  */)
>>      (Lisp_Object f1, Lisp_Object f2)
>> {
>>   bool res;
>>   if (EQ (f1, f2))
>
> This EQ can also trip.  Sorry to insist on that, but I think it's an
> important point: if we change Lisp internals (such as the slow EQ
> thing), the "we're not dereferencing it, just looking at the bit
> representation of the pointer" approach will fail again, in unexpected
> places.
>
> I haven't seen a technical argument against using separate stacks for
> MPS and signals (I don't consider "it's a change and we'd need to test
> it" to be any more true for this change than for any other proposed
> change, or for what's in scratch/igc now).  It would get us on par with
> master.  (Both versions need to add the best memory barrier we have to
> the specpdl_ptr++ code)
>
> (I don't think MPS works on multi-threaded systems if word stores aren't
> atomic.  If thread A is in the middle of updating an mps_word
> referencing another object, and thread B triggers a GC, thread A is
> stopped and thread B might scan the segment in the inconsistent state.)
>
> Miraculously, everything can be made to work out in the WIDE_EMACS_INT
> case, even though 64-bit words are stored in two insns: we only look at
> the LSB 32-bit word when fixing (because we USE_LSB_TAG), so that'll
> just work.  Late exthdr creation needed to be changed a little, and now
> assumes changing a 64-bit value to another 64-bit value which differs
> only in one 32-bit half is atomic.
>
> Here's a snapshot of the current code.  It still assumes strong memory
> ordering between threads because I'm pretty sure MPS needs that, too, so
> it's just asm volatile ("" ::: "memory") for now.

Thanks.