Re: scratch/igc: Implications of MPS being asynchronous

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> I think the main question is whether the font cache can be compacted by
> ordinary code, or whether it needs to use MPS weak objects with all
> their problems.  This depends on the font code and I need to study it:
> there's no way to do things as precisely as the old GC does.

Very hard to read, that code. A use of the font cache is in
font_matching_entity, call of font_get_cache. I think. There is also
where something lands in the cache.

That looks pretty "harmless". If entries are removed, font_drive::match
is called, which will take more time, presumably, because system
functions are called, in macfont_match, for example.

But that's it I think. And that is consistent with the mere existence of
clear-font-cache. I don't see leakage of anything by that. Famous last words.

> The old GC keeps a font cache entry alive if one of the font-entity
> values is still reachable, and I don't understand why: there's no way to
> go back to the cache entry or the font spec from the entity, is there?
>
> To put it bluntly: if we unconditionally call clear-font-cache a lot,
> will we leak memory?  If so, the function shouldn't be exposed to Lisp.
> Otherwise, let's just do that every seventh GC or for any GC if it's
> been an hour.
>
> I see some minor flickering here, barely noticeable.  Could you let me
> know if this issue is so much worse on other systems that we might have
> to think about it?

You mean after clear-font-face? I'm not noticing something. I don't have
very many fonts though.