Re: MPS: dangling markers

[Pip Cet <pipcet@protonmail.com>]

On Sunday, June 30th, 2024 at 04:41, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Pip Cet pipcet@protonmail.com writes:
> > (Implementing weak hash tables with MPS seems quite difficult, though:
> > you can have only one "dependent object" with strong references per
> > object with weak references,
> 
> Yes, the one dependent object is somewhat limiting. I though yesterday
> that using something like a weak doubly-linked list could be the
> solution for the markers, but that would require 2 dependent objects,
> next and prev. Anyway.

I checked in the MPS source code (which, I understand, you don't want to modify), and the limit appears to be something that can be raised easily...

> > And since we can't resize objects that may be pinned by ambiguous
> > references, well, the weak hash table implementation would look quite
> > different from the strong hash tables we have).

> I thought that, very roughly, the following might be doable:

I'm afraid that wouldn't be doable in general, though whipping something up for the special case of markers might be easier. If we had a recipe to measure the performance problem, I could benchmark my strong hash table "solution" to see whether it makes sense to pursue that further.

> If we make-hash-table with weak keys and/or values, allocate the
> Lisp_Hash_Table from the AWL pool using the weak_strong allocation
> point. If neither keys nor values are weak, allocate the hash table from
> the default pool.

> Allocate the key and the value vector according to the hash table's
> weakness either from the strong or weak allocation point, or from the
> default pool if the table isn't weak at all. (I've split the
> key_and_value vector already in two, but you probably noticed that
> already.)
> 
> Dependent object of the key and value vectors could be the hash table
> itself.

Then we couldn't modify the value vector when the key gets splatted, or vice versa, so the table wouldn't be properly weak. My understanding is we must allocate all strongly-referencing objects together in one object, all weakly-referencing objects together in another one, and make them depend on each other. And that means making the pseudovec a mere tuple of pointers to the strong and weak parts, because the conglomerate objects might need to be resized...

> The weak pool currently only contains the weak vectors for markers, the
> markers themselves live in the default pool.

Oh, sorry. You're right, of course.

Pip