Re: MPS: marker-vector

[Pip Cet <pipcet@protonmail.com>]

"Helmut Eller" <eller.helmut@gmail.com> writes:
> On Mon, Aug 05 2024, Pip Cet wrote:
>> I see one somewhat theoretical problem with this patch: if a marker is
>> simultaneously kept in a weak hash table, it's possible for it to be
>> splatted from the marker vector while remaining in the weak hash table
>> (there's no guarantee all references will be splatted at the same time);
>> if it is then retrieved from the weak hash table and made to point
>> nowhere, we will try to remove it from the marker vector, and hit the
>> igc_assert.
>
> Never thought about this.  Hm.  I think MPS could easily guarantee that
> all references are splatted at the same time: we could think of
> splatting a reference like moving an object to address zero.  MPS
> certainly guarantees that all references to a moved object are updated
> before they are seen by user code.  MPS could do the same for splatted
> references.

I don't know MPS internals very well, but IIRC weak objects can be
scanned with or without splatting depending on whether the program hit a
barrier or a regular GC opportunity.  I don't know why that is,
though. It may be related to the unfortunate
emulated-single-access-on-IA32 thing.

>> The rest of my comments are tiny nits, really:
>>
>> - capacity isn't redundant on 32-bit systems
>
> Not sure what you mean.  Certainly igc_header_nwords works on 32-bit
> systems too; and igc_header_nwords is pretty much the same as capacity.

Except it's rounded up to multiples of 64 bits on 32 bit systems, making
it impossible to represent a vector of odd length.  Of course that
doesn't happen in the code you posted (which starts with 2 entries and
doubles the vector size when a larger vector is needed, resulting in an
even number of entries at all times), so I apologize for not seeing that
right away.

>> I wonder whether it wouldn't be faster, upon encountering a marker that
>> has been splatted, to fix the entire array all at once. That would
>> ensure that creation order is respected, and splatting is relatively
>> rare (and, when splatted, we can expect most of the array to have been
>> splatted; indeed, I suspect it'd be best to give up on the marker vector
>> and build a new one so the old one can be collected and we don't have to
>> worry about never shrinking it).
>
> Possibly.  But I also decided to ignore the issue and happily let
> somebody else come up with a benchmark that shows that any of this
> matters.

Okay, let's stay with the current code for now and revisit the issue
when the time comes?

Pip