Re: Building the igc branch on MS-Windows

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

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 09:23:17 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So this is progress, but now the font structure of a face is invalid,
>> > so some other protection is missing somewhere.  Any ideas?
>> 
>> Maybe it's the ascii_font that I found in the other mail? If you give me
>> an hour I can look into this. Or you could check if fix_face does all it
>> needs to trace... And maybe fix_font.
>
> There's no fix_font, AFAICT.

Ah, okay, I misrememberd that, sorry. PVEC_FONT is currently traced as a
simple vectorlike, i.e. only Lisp_Object members.

There is one thing in struct font I'm not sure about. it has

  font -> font_driver -> Lisp_Object .type

where type is a symbol from DEFSYM under macOS. Being a DEFSYM means
it's immortal and immovable, of course, which means we don't need to
trace it. But strictly speaking it should be traced, just to not
introduce hidden assumptions. Or maybe it's already demanded somewhere
that that is always the case. And of course I have no idea what other
plaforms do...

> In fix_face, I think these should be added to scan:
>
>     struct font *font;
>     struct face *next, *prev;
>     struct face *ascii_face;

These three in any case, yes.

>     void *extra;

What that is I have no idea. 

> 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.

Wrt to tracing interior pointers I'm not entirely sure, because I had
one case only, so far: buffers have a pointer to their text, which is
either the address of own_text or the one of its base buffer. I've taken
the easy way out and compute the text pointer each time the buffer is
traced. Don't know ATM, hat the situation is with a face's font.

One related factoid is probably worth mentioning:

While our scanning callbacks run, MPS guarantees us exclusive access to
only those objects in the address range MPS calls us for. All other
objects are (potentially) behind read/write barriers. So we can't change
something in object A while scanning a different object B.

This does not hold for objects that are not managed by MPS. If B has a
pointer to malloc'd memory M, we can do with M what we want, but MPS
also doesn't protect M from other threads. We're on our own.

Reads a bit bumby. Hope it helps anyway.