[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some experience with the igc branch
From: |
Gerd Möllmann |
Subject: |
Re: Some experience with the igc branch |
Date: |
Thu, 26 Dec 2024 06:27:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: Some experience with the igc branch, (continued)
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Pip Cet, 2024/12/27
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/27
- Re: Some experience with the igc branch, Pip Cet, 2024/12/27
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/28
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch,
Gerd Möllmann <=
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/26
- Re: Some experience with the igc branch, Pip Cet, 2024/12/24
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/25
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Pip Cet, 2024/12/25
- Re: Some experience with the igc branch, Stefan Kangas, 2024/12/25
- Re: Some experience with the igc branch, Pip Cet, 2024/12/25
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/26