Re: MPS: User GC customizations

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

>> Define GC, so to speak, and define what triggering the GC means in a
>> concurrent, incremental GC :-)
>
> AFAIU, the points of interests from real-time performance perspective
> are (1) when MPS has to pause the threads to do its job and how we can
> tweak it; (2) how long does it take to scan the arena to allocate new
> objects (synchronous process) and how this time is influenced by MPS
> settings.

Right. Alas, we don't have something for that. (And I don't know how to
do it either.)

>
>> What this variable does is give MPS notice that the client is currently
>> idle and it might be a good time to do some work.
>
> Without understanding what effect setting this variable has on the Emacs
> responsiveness, it does not seem very useful. (Exactly because MPS is
> concurrent)

That was kind of my point. We can use idle time for using this variable
and see what effect it has, especially in interactive use. Sorry if that
wasn't clear. I'm personally trying 0.1 (100ms) here at the moment.

>>> For example, my recent measurement of building agendas displayed 30% of
>>> the time spend in GC. (whatever this means in the context of our handling
>>> of SIGPRF)
>>
>> Exactly, whqt does it mean? And if we don't know, why is it an example
>> for anything?
>
> AFAIU, on master, SIGPROF handled while our vanilla GC is running
> will record it. In contrast, on scratch/igc, SIGPROF will put all the
> time when igc_busy_p () is non-nil into "GC".

Right. And I wonder if that simply is because MPS is doing stuff in its
own thread.

> And igc_busy_p is not only non-nil when MPS is pausing Emacs to do its
> job, but also during object allocation. So, on master, profiler "GC"
> field records real GC pauses, while on scratch/igc "GC" field is GC
> pauses + new object allocation.

The docs say

 -- C Function: *note mps_bool_t: 129. mps_arena_busy (mps_arena_t
          arena)

     Return true if an *note arena: 16. is part of the way through
     execution of an operation, false otherwise.

     ‘arena’ is the arena.

          Note: This function is intended to assist with debugging fatal
          errors in the *note client program: d0.  It is not expected to
          be needed in normal use.  If you find yourself wanting to use
          this function other than in the use case described below,
          there may be a better way to meet your requirements: please
          *note contact us: d8.

What "partly through an operation" means is anyone's guess at this
point. Someone would have to consult the sources. The docs don't say
what you are suggesting, from my POV.

> My figure of 30% says that igc_busy_p () is for 30% of CPU time, which
> is a significant number. But it is not very useful unless we get some
> idea about which part of it is memory allocation and which part of it is
> MPS pausing all Emacs threads.
>
> Ideally, we should also have some way to get the allocation times on
> master. Then, we can compare them directly.

Maybe it would be interesting what the meansurements look like on macOS,
where the check for igc_busy are not needed in the SIGPROF handler.

Anyway. I'm not working on this, I just wanted to promote the variable
as a knob that one can play with.