Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 11:04:40 +0200
>> 
>> > If some of those are not needed to be scanned, then maybe I don't
>> > understand the criteria for scan-ability?  Would you please explain
>> > the basics here, like MPS 101 thing?
>> 
>> Ok, it's easy, and you already did TRT.
>> 
>> References interesting for MPS are Lisp_Objects and pointers to objects
>> in MPS. The need for tracing pointer references is new compared to
>> non-MPS. It must be done because objects move in memory.
>> 
>> Tracing pointers to non-MPS objects is not necessary. Ideally, it costs
>> only some cycles. At least that's my understanding, that it does no
>> harm.
>
> Let me understand the meaning of this for our usual Emacs coding
> style.  We use the following paradigm _a_lot_:
>
>   struct window *w = XWINDOW (some_window);
>   /* ... much later ... */
>   do_something_with (w);
>
> (The do_something_with doesn't have to be a function call, it could be
> some comparison with another 'struct window' pointer, or dereferencing
> w to access some field of 'struct window', etc.)

Ok.

> Given that now the some_window object can move in memory as result of
> GC, what does it mean for code like above?  Will MPS magically update
> the pointer in w to point to the new location, or use VM protection to
> redirect any accesses to the pointer in w to the new location?  For
> that matter, can GC even happen between XWINDOW and do_something_with?
> Since GC is (AFAIU) asynchronous and runs in another thread, what can
> trigger GC while the Lisp thread runs code like above?  Do we now have
> to be cautious with accessing Lisp objects via their C pointers, like
> we did until now with Lisp strings and buffer text?
>
> Is the above a real issue, or is it already taken care of for us by
> MPS?

Yes, it is taken care of.

MPS scans the control stack as an ambiguous root. It is more or less
what the old GC does in that references found on the stack keep objects
alive. In addition to keeping objects alive, ambif references also
prevent moving these objects because we don't know if the reference is
"real" or just a random bit pattern. That's the "mostly" in the
mostly-copying idea, for which one could at one time get a patent :-(.