Re: scratch/igc: Keeping a TODO list?

[Pip Cet]

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

> On Sun, Jan 12 2025, Stefan Kangas wrote:
>
>> In a previous discussion, I suggested starting to maintain a list of the
>> things that remain doing on the scratch/igc branch before it can be
>> merged to master.  This would be useful both for prospective
>> contributors, and so we don't forget or lose track of anything.
>
> I liked Gred's message where he basically said "let's ignore this talk
> about merging with master".  I for one consider scratch/igc as
> experimental for the foreseeable future.
>
>> Gerd, Pip, Helmut, do you agree that this would be useful?  If yes, is
>> it a good idea to continue using this file as the canonical TODO, or
>> should we keep such a list in some other format or file?
>
> 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):

1. go over all of Emacs's signal handlers again to ensure they never
attempt to access MPS memory.  Document this permanent limitation on
what Emacs signal handlers can do.

2. start background collections on a separate thread to shake out bugs.

3. change the bytecode reading code to make stack usage >
HORRIBLE_ESTIMATE illegal.

4. split large vectors and hash tables into several reasonably-sized MPS
objects.

5. remove no-barrier assumptions for string data (or fail and document
those assumptions)

6. use protected roots where we can.

7. use MPS memory allocation rather than roots for things like the
specpdl

8. use malloc()/memcpy()/free() rather than realloc(), remove the arena
parking when a root is "resized"

9. guard against passing MPS memory which is potentially behind a
barrier to syscalls

10. Ban WIDE_EMACS_INT + HAVE_MPS builds again.


Maybe it's more interesting what's not on the list:

1. Rewrite bytecode stack handling to remove the HORRIBLE_ESTIMATE
thing.  I understand someone else is working on that.

2. Modify MPS to handle resizing roots.  Roots should be small enough
that the malloc()/register/memcpy()/unregister/free() approach works.

3. Modify MPS to use double-mapping.  I still think this would reduce
the need to suspend other threads while MPS scans a segment, but we're
not even sure that's an issue yet right now; even if it is, that's
probably an indication we need to do (4) above.

4. Modify the old GC to preserve SDATA pointers.  I've done that
locally, it works, fixing the performance implications of removing
pin_string seems possible: this is the right thing to do but there's no
chance we will do it.

5. Many other changes in the right-thing-to-do-but-vetoed category.

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.


Of course, all that's assuming we don't decide to fundamentally alter
the design of scratch/igc to make no-GC assumptions.

Pip