Re: scratch/igc: Keeping a TODO list?

[Helmut Eller]

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.
  2. Create a separate pool for conses.
  3. Teach the dumper about the new pool.
  4. Actually remove the gc_header.
  5. Come up with evidence that this is worth doing.

  Status:: I've done steps 1-4 in a local branch.

  Todo:: Need to clean up the code, rebase it, more testing.  And
  step 5.

* 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
  restriction only creates a problem on Intel 386 machines.
  
  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.
  
  Todo:: We need to work with MPS people to fix this.  At least open
  a GitHub issue.

* 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.  The wrapper is a
  root that we can trace while the client doesn't need to know whether
  the GC moves objects or not.  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.

  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
  that GC handles must be manually freed.

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


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

scroll-xdisp.el
Description: application/emacs-lisp

Helmut