Re: igc, macOS avoiding signals

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Mon, Dec 30 2024, Gerd Möllmann wrote:
>>> Anyway, it definitely seems to be the case that MPS is _not_ running GCs
>>> concurrently, unless it would do things that I find highly unlikely.
>>>
>>> I find that a bit, let's say, disappointing, TBH :-(.
>>
>> Richard Brooksby thinks[*] that MPS could be concurrent with software
>> barriers.  Feel like going down that road? :-)
>>
>> Helmut
>>
>> [*] 
>> https://memory-pool-system.readthedocs.io/en/latest/design/shield.html#concurrent-collection
>
> Yep, found that too, with git grep.
>
> Still grumpy.
>
> I'm afraid Modifying MPS is not my thing, But What about using something
> more modern like Oilpan (aka cppgc) from V8? Can be used as a lib, is
> concurrent for real. That would also be a perfect time to lift Emacs to
> C++.

Ultimately, I'm still surprised there isn't that much work on precise GC
with compiler support, allawing us to mark the C stack precisely by
emitting DWARF tables indicating precisely which registers or stack
locations references live in at the time of an interruption.
(Identifying them is the easy part.  Emitting only code which allows you
to move such references asynchronously is the hard part).

But if you're doing all that, why not go all the way and implement
resumable exceptions?

(I wasn't going to mention it, but there's always my experiment with the
SpiderMonkey garbage collector.  Lots of bitrot, and I never got things
working quite the way I wanted to (no ambiguous references)).

Pip