Re: MPS: dangling markers

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

Pip Cet <pipcet@protonmail.com> writes:

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

Interesting to hear! (I don't even want to read MPS, only lots of
uninteresting details... :-)).

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

True. I forgot to mention an important thing: When something is splat,
set flag(s) in the dependent hash table indicating that something must
be done because of that splatting. In gethash and so, check the flag and
do what's necessary. (I did something similar for the weak hash tables
in CMUCL, and it wasn't entirely bad. And weak tables should be rare.)

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

The first 2 points I think are true, and are the reason I split the 1
vector in master containing both keys and values into two in igc, so
that keys and values can be weak or not, as necessary.

The 3rd thing you wrote I'm not sure. My understanding is that
specifying a dependent object simply means that MPS makes it accessible
while scanning the depending object. I don't think MPS does anything to
the dependent object by itself. Hence the idea to make the hash table
the dependent object so that one at least can "notify" it that something
has happened, so that it can modify index and next vectors.

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

I'm afraid I couldn't follow. Could you please explain?