Re: Some experience with the igc branch

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

"Stefan Kangas" <stefankangas@gmail.com> writes:

> Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>>> I think that's already true for the old GC. There is nothing
>>> guaranteeing that the contents of the binding stack is consistent, for
>>> example. But we get away with it well enough that the profiler is
>>> useful.
>>
>> My understanding is that was true at one point, before C caught up to
>> memory ordering between a thread and its signal handlers, but with C11,
>> we have everything we need to ensure consistency, at least on systems
>> that store words atomically (we don't use memcpy for modifying the
>> specpdl stack).
>
> Which parts of C11 help us?

stdatomic.h, in this case.

Please take the rest of this email with a grain of salt: as far as I
know, compilers and I have reached the promised land of explicit memory
barriers, and I'm actively trying to forget about the precise rules
surrounding implicit memory barriers in the old days.

The summary is we should explicitly indicate thread/signal data
dependencies (atomic_signal_fence) in new or modified code, and
explicitly indicate thread/thread dependencies in new code
(atomic_thread_fence).  If the compiler doesn't support it, we must
assume it's too old to reorder stores.

https://github.com/rmind/stdc/blob/master/c11memfences.md seems to
mostly agree with my memory, though.

IIRC, C99 doesn't have usable memory barriers, not even for signal
handler/main thread races such as this one.

Of course almost every compiler that supports C99, and certainly all
compilers usable for compiling Emacs, provides (or doesn't need, in the
case of TinyCC) ways of implementing them.  In the case of GCC, that
used to be asm volatile ("" : : : "memory").

> I'm probably missing something obvious, but aren't we using C99 on the
> scratch/igc branch also?

We're using C99 + a lot of assumptions (most importantly, conservative
scanning lore).

If my memory is correct, this particular assumption (as far as the
compiler goes) changed from "C won't reorder stores" to "C won't reorder
stores across a non-inlined function" (where "non-inlined" changed from
"not explicitly inlined", then "in another CU so it can't be inlined",
then to "explicitly defined as non-inlined"), and finally to "you have
to tell C explicitly not to reorder stores".

Emacs hasn't caught up with the final change, so we're currently in a
"nothing guarantees that it'll work, but it kind of does" stage with
regard to the specpdl and profiling.  Very old compilers don't support
or require explicit memory barriers; old compilers support but don't
require them; current/future compilers may require them.

Note that Gerd appeared to be disagreeing about some part of this, but
I'm not sure which part precisely.

Pip