Re: Some experience with the igc branch

[Pip Cet]

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

> Pip Cet <pipcet@protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>>> I've reached the point where I don't know what else to explain. Could
>>>> always be improved, of course, and so on. Please find attached, with
>>>> request for feedback.
>>>
>>> Ahem, just remembered that I had already an admin/igc.org in the branch,
>>> so I've now replaced that with what I've written.
>>
>> Thank you very much!
>>
>>> - Concurrent.  The GC runs in its own thread.  There are no explicit
>>>  calls to start GC, and Emacs doesn't have to wait for the GC to
>>>  complete.
>>
>> I don't think that's true right now (it is what I want for Christmas,
>> though).  On GNU/Linux, the GC usually runs on the main thread.  On
>> macOS, the GC can run on the main thread (allocation) or on the SIGSEGV
>> handler thread (memory barriers); in both cases, the main thread has to
>> wait for it to complete.
>
> You mean what happens when an allocation point has used up its memory,
> and needs to get some more?

That's usually what triggers GC here, IME (but then, my experience
represents an atypical situation, where we never become idle.)

> I haven't looked what percentage of GC time
> that takes. Also, the GC steps I didn't mention.
> One has to make a cut somewhere.

Fair enough.  We should never assume that GC runs on the same thread, so
writing that it never does may be a justifiable lie here.  We also
shouldn't assume that it's on a separate thread, but that's only
relevant to signal handlers.

Pip