Re: Some experience with the igc branch

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: pipcet@protonmail.com,  ofv@wanadoo.es,  emacs-devel@gnu.org,
>>  eller.helmut@gmail.com,  acorallo@gnu.org
>> Date: Wed, 25 Dec 2024 13:50:37 +0100
>> 
>> >   . how is accessing F different from accessing the specpdl stack?
>> 
>> F's memory is allocated from an MPS pool via alloc_impl in igc.c. Most
>> objects are allocated from a pool that uses barriers (I think except
>> PVEC_THREAD). The specpdl stacks are mallocs (see
>> grow_specpdl_allocation), and uses as a roots. There are currently no
>> barriers on roots.
>
> So you are saying that the answer to this:
>
>> > The first question is more important, from where I stand.  Looking
>> > forward beyond the point where we land igc on master, I wonder how
>> > will be able to tell, for a random non-trivial change on the C level,
>> > whether what it does can cause trouble with MPS?  That is, how can a
>> > mere mortal determine whether a given data structure in igc Emacs can
>> > or cannot be safely touched when MPS happens to do its thing, whether
>> > synchronously or asynchronously?  We must have some reasonably
>> > practical way of telling this, or else we will be breaking Emacs high
>> > and low.
>
> is that we need to trace each datum to see whether it is "used as
> roots" (what does that mean in practice, btw?) or is "allocated via
> alloc_impl in igc.c"?  Does the latter include all the Lisp objects
> (except fixnums)?  Do we allocate non-Lisp data via alloc_impl, and if
> so, which data?

No, I'm not saying anything like that. Apparently I've used some
hints/terms that you are not familiar with. Sorry for that.

Roots: There are GC roots in the old GC. Specpdl stacks are roots,
DEFVARs, control stacks, DEFSYM symbols, the bytecode stacks and so on.
They are marked first at the beginning of GC. The roots and everything
recursively reachable from them are all live objects.

Roots in igc are basically the same thing. There are MPS function with
which one can define roots, if you mean that by "what it means in
practice". These MPS functions are called in igc.c. Please don't ask
which functions :-).

alloc_impl: This function is used for the allocation of all Lisp
objects, vectors, strings, frames, everything that can end up being
references as Lisp_Object. So everything except fixnums. And it is not
used to allocate other stuff, the xmalloc family of functions is used
for that.

WRT to the mere mortal and so on: I was talking specifically about
get_backtrace, and why it can be used as-is, in the way I described, to
get a backtrace in the SIGPROF handler. What's the problem with that? I
think what you write is a grossly exaggerating the situation with "trace
each datum" and a bit implying "all the time" (re your paragraph below).

Does that help?

>
> Once again, I think this is very important for future maintenance.  I
> feel that this barrier thing in MPS introduces significant
> complications into reasoning about safety of C-level changes.
> Previously, we only had the mark bit to worry about if we wanted to
> access Lisp objects during GC (see gc_asize, for example), but now we
> have a much larger problem, AFAIU.  How do we manage that for the next
> 40 years?

These problems do not exist. The barriers are transparent for the
application, except in vary special circumstances, namely this shit
signal handler.