Re: MPS image cache

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

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sun, May 05 2024, Gerd Möllmann wrote:
>
>> I'm plannign to do the following if nobody stops me:
>>
>> Both face an image cache are hash tables containing 2 arrays of pointers
>> to MPS objects (face, image).
>>
>> I want to introduce a new MPS object type representing such an array of
>> pointers, IGC_OBJ_PTR_VEC. The igc_header gives us the size of the
>> array, and being an MPS object, we get exclusive access to its contents.
>>
>> WDYT
>
> Would something like this also be needed for glyph matrices?  

Probably. Either we make the matrices roots, or objects, I guess. For
correctness. We can't easily realloc when they are objects, but I don't
think that's a big problem.

> Or in general, can we scan anything other than the block that
> dflt_scan was called with? 

Let's say we shouldn't :-). MPS lets us scan memory it doesn't manage,
but with multi-threading it's not really safe.

> Is these related to "remote references" in the MPS manual, which I
> don't quite understand what they mean.

That's this

  A reference that logically belongs to a formatted object and so must be
  fixed when the object is scanned, but which is not stored within the
  block containing the object. (For example, in an auxiliary table of some
  sort.)

  The MPS does not generally support remote references because those
  references may be protected and so if scan method attempts to fix them
  this will hit a barrier (1) and cause a re-entrant call to the MPS.

My interpretation of this is that we may only fix12 references withing
in an object that is currently scanned (is in the address range for
which MPS called us). We may not extend the scan to other MPS objects.

Let's say we are scanning a symbol S. The reference to S->name can/must
be scanned, but S->name->intervals or something is taboo because S->name
may be behind a barrier.

Made sense to me.