Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I now see this comment in compact_font_caches:
>>
>>   compact_font_caches (void)
>>   {
>>     // Cannot be done with MPS, which doesn't seem to be tragic
>>     // because there is an option to turn it off.
>>   # ifndef HAVE_MPS
>>
>> Why cannot font caches be compacted with MPS?
>
> AFAICS, I added this on 2024-03-20, i.e. ca. 4 weeks after I started.
>
> What I meant with the comment is that it cannot be done in the same way
> it is done in the old GC. If you look at compact_font_cache_entry,
> you'll see that it checks if things are marked, and if not drops them.
> It's similar to weak hash tables in the old GC.
>
> I skipped weak structures for learning MPS, so I just left this out. For
> MPS, some other weak structure would be needed, If one wants that. Maybe
> a weak hash table could be used for the font cache?

While weak hash tables may continue to be necessary (I'm not sure about
this), for internal data structures we control, finalizers are
better:

When you allocate a font structure, allocate an extra cons cell which
you always use to refer, via XCAR, to the font structure.  Except that
in the hash table, you use the car directly.  When the cons cell is no
longer reachable (the font structure still is, because it's in the hash
table), the finalizer will eventually run, and then you can remove the
hash table entry from the hash table, eventually freeing the font
structure, too..

Note that this works with MPS finalizers (slow) and struct
Lisp_Finalizer finalizers (even slower).  We should prefer the former as
Lisp finalizers don't behave precisely like MPS finalizers; right now,
we just use MPS behavior for Lisp finalizers, but that doesn't match the
documentation in every detail.

Pip