Re: scratch/igc: Keeping a TODO list?

[Pip Cet]

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

> On Sun, Jan 12 2025, Pip Cet wrote:
>
> [...]
>>> It would be useful to know who works on what.
>>
>> Here's what's on my TODO list (feel free to create an Org-mode TODO file
>> with a few entries and then I'll try to add these in the right format):
>
> Here are some of mine:
>
> * Headerless conses
>   Goal:: Remove gc_header from struct Lisp_Cons
>
>   Description::
>   1. Adapt hash tables to use MPS's location dependencies to avoid the
>      need for the hash code in the headers.

Just to repeat myself, I don't think we should do this:

MPS location dependencies are one huge GC-is-rare assumption, aren't
they?  So even if this would be worth doing today (before we even
started fine-tuning MPS parameters), it would be a perverse incentive
not to improve the rest of the GC code.

And if we want to save space for conses (we're several decades beyond
this point, IMHO), we should look at storing lists efficiently, omitting
the cdrs, and constructing the cons cells on demand only when they're
written to.

Lastly, giving up sxhash-eq (without providing a replacement, such as a
stable ordering of objects) means deciding that no one gets to implement
efficient hash-table-like data structures in Lisp, ever again.

> * Tagged pointers in the AWL pool
>   Goal:: Allow us to have tagged pointers in the AWL pool
>
>   Description: The AWL pool has special constraints on the object
>   format: references must be aligned pointers.  However, the

Worse, aligned words must be references.

>   restriction only creates a problem on Intel 386 machines.

Even on those, only for instructions matching specific patterns:
"mov (%eax),%ebx" doesn't match, but "mov 8(%eax),%ebx" does.

>   Status:: The marker vectors happily ignores the issue while the weak
>   hash table code goes to great pains to satisfy the constraints.  A
>   strange situation.

Let's not forget that the MPS header manipulation code is also painful
to read because of these constraints.

>   Todo:: We need to work with MPS people to fix this.  At least open
>   a GitHub issue.

We should.  I have a very dirty workaround in mind to make sure old MPS
versions never see an instruction they might try to emulate.  If MPS
decides to drop the aligned-pointers = references requirement for AWL
for *future* versions (it'd suffice for it to be made optional, of
course), we can install the workaround for past versions, and never
worry about this again.

> * GC handles
>   Goal:: Introduce GC handles to hide moving objects from naive
>   clients.

>   Description:: Instead off handing out plain Lisp_Objects, create a
>   malloced wrapper that contains the Lisp_Object.

Ideally, a ref-counted one, to reduce the number of roots/AMS objects.

>   The wrapper is a
>   root that we can trace while the client doesn't need to know whether
>   the GC moves objects or not.

If we know it contains a Lisp_Object (or a pointer), it doesn't need to
be a root, just immovable and referenced from some global object.

>   This would mainly be useful for:
>
>   1. GUI code that commonly uses some void* to attach extra
>      information.  The void* would be a GC handle instead of a
>      Lisp_Object.

glib_user_data should certainly be changed to do something like this
(if I understand it correctly).

>
>   2. Dynamic modules.  Those certainly shouldn't need to how the GC
>      works.
>
>   GC handles would allows us to ditch the AMS pool.  A disadvantage is

I'd prefer reducing the number of roots and keeping the AMS pool, if we
have to choose.

>   Todo:: convince the powers that be that this is worth doing.

I don't think that includes me, but I'm convinced: the GTK thing is
likely a blocker, and this seems like the best fix for it.

>> 6. Performance optimization.  I'd appreciate any work in that direction,
>> but it really depends on having a large and flexible benchmark suite,
>> and it currently looks like we can't even merge elisp-benchmarks.
>
> BTW, here some nice code to emulate Eli's "open xdisp.c and lean on C-v"
> benchmark:

Thanks!

Pip