emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some experience with the igc branch


From: Gerd Möllmann
Subject: Re: Some experience with the igc branch
Date: Fri, 27 Dec 2024 17:05:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

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? 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.

Anyway. If people agree that something should be there, please add it.

That's the advantage of it being in git.
For me :-).

> I'm not sure it's ever useful to make the assumption that GC isn't
> concurrent:  it is very hard to do so, but it is possible.
>
> Maybe Eli knows more; I posted a patch to force concurrent GC for
> debugging a while ago, and Eli told me not to because it would produce
> false positives.  I'm not so sure about the "false" part now.
>
> Pip



reply via email to

[Prev in Thread] Current Thread [Next in Thread]