Re: Some experience with the igc branch

[Pip Cet]

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

> On Mon, Dec 23 2024, Pip Cet wrote:
>
>>> sxhash_eq doesn't fly with headerless objects.
>>
>> Which objects would that be?
>>
>> Right now all IGC objects have headers, right?  Did I miss any?
>
> Right, but I'd like to keep that option on the table.

I see one specific case where it would be useful: storing 64-bit
integers on 32-bit systems.  We don't need the entire integer range,
since -256M .. +256M - 1 are fixnums (assuming we reduce fixnum range by
1 bit).  So we have 512M unused values, which is precisely the number of
possible forwarding pointers if we maintain 8-byte alignment.  We can
use two "impossible" forwarding pointers for 1-word padding and N-word
padding, so this case works out precisely.  No hash problems, since a
u64 is constant and we can hash the contents instead.

The only relevant 2-word object is conses, and I don't see a way to do
it for them.

Most N-word objects with N>2 are either fairly large to begin with, or
they're vectorlikes and we have a redundant size field, which we can get
rid of.

>>> It should be obsoleted, IMO.
>
> [...]
>> That leaves conses.  My guess so far was that you wanted to implement a
>> hack where a headerless cons is a two-word object that would turn into a
>> tagged pointer to another two-word object with a header as soon as its
>> hash value is taken.  That requires slowing down either XCAR or XCDR, I
>> think, and that's sufficient reason for me not to do it, but I guess I
>> misunderstood your plans.  This would also mean sxhash_eq would allocate
>> memory, so it couldn't be called from a signal handler without yet
>> another workaround.
>
> I would go the obvious way: use segregated allocation.  Each Lisp_Type
> gets its own MPS pool, without igc-headers.  The dflt pool would only

Why bother for non-conses?

> contain non-lisp types, like IGC_OBJ_STRING_DATA, with igc-headers.
> That wouldn't slow down XCAR, but it requires that hash tables use MPS's
> location dependencies.

I don't think we want to use location dependencies: even if we solved
all the other problems (Fsxhash_eq, permanent hashes for those places
where we can't rehash), I'm pretty sure rehashing would kill us.  In
particular, if we somehow managed to make GC more fine-grained and move
fewer objects, we'd end up rehashing more, so suddenly we'd have an
incentive not to use minor GCs.

But I confess that I haven't looked at the location dependency code.
There's no need for us to use it, and from the documentation it seemed
it wouldn't be a good idea to start using it if you don't have to.

(Also, at that point, shouldn't we just use an AMS pool for conses?)

Pip