Re: Some experience with the igc branch

[Pip Cet]

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

> On Mon, Dec 23 2024, Pip Cet wrote:
> [...]
>>> Also worth mentioning is that trace_hash uses XHASH, which is probably
>>> problematic in combination with a moving GC.
>>
>> Good catch.  s/XHASH/sxhash_eq/ there, I think?  And let's poison XHASH
>> when MPS is in use?
>
> 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?

> It should be obsoleted, IMO.

I don't see why.

Is this about cons cells exclusively?  Because 3 words/cons is too
much (possibly 4 words on W64 or 32-bit systems)?

For vectors we can usually derive the length of the vector from the IGC
header (which has plenty of extra bits), which would have the equivalent
effect.  Strings, symbols, floats shouldn't matter.

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.

(Note that cons cells used to store long lists are inherently
inefficient: naively storing an n-element list with a header requires
n+1 words, but even headerless cons cells will require 2*n words.  So if
we really decide we need to reduce cons memory usage, I'd look into that
instead.)

Pip