Re: [MPS test] Is there some customization options for `scratch/igc` feature?

[Pip Cet <pipcet@protonmail.com>]

"Eval Exec" <execvy@gmail.com> writes:

> I'm helping to test `scratch/igc` branch (commit id: 42731228d24) .

Thanks again! Any news on the X toolkit problem, or can I push that
patch?

> At start, my cursor is in buffer's top line, I long press [down] key
> and don't release, expect the cursor will move to bottom line. I feel
> lag, and buffer window doesn't update until I release [down] key.

I can reproduce this behavior, kind of, if I build with CFLAGS="-O0 -g3
-ggdb", my usual set; in an optimized build, things seem to work out
more like I would have expected.

> Then I see there is some message in `*Message*`:
> ```
> Garbage collecting...
> Generation 0 of a chain has reached capacity: start a minor collection.
> Garbage collecting...
> Generation 0 of a chain has reached capacity: start a minor collection.
> Garbage collecting...
> Generation 0 of a chain has reached capacity: start a minor collection.
> Garbage collecting...
> Generation 0 of a chain has reached capacity: start a minor collection.
> Garbage collecting...
> (many...)
> ```

What that means is that many garbage collections happen, which may be
unexpected or not depending on how many "many" is...

> What's the `capacity`?

All allocations in MPS happen in a generation; once the total size of
objects allocated in that generation reaches the "capacity", a minor GC
is triggered, which may take a long time during some of which the
generation is larger than its capacity.  So it's a bit of a misnomer.

> how can I config the `capacity`?

Right now, you have to go to igc.c and edit the line which reads:

  mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };

That means that there are two explicitly-specified generations: the
first has capacity ~128 MB (128000 times 1024 bytes), the second ~640 MB
(5 * 128000 * 1024 bytes). There's also an implicit last generation
which is "unlimited" in size and holds objects which have survived
collection twice.

The 0.8 and 0.4 values specify a mortality prediction for each
generation: this value is updated by MPS, so it's not that relevant.

It'd be nice to be able to change these values at run time, but MPS
doesn't seem to offer an API to change them then: we'd have to create
new pools with the new generation chain, and stop allocating in the
existing old pools.

The other problem is that the values are needed very early during Emacs
initialization, so the usual customization options aren't available.

On my branch, I've implemented a command line option which is parsed
early and specifies the sizes of the generation chain, so I can
experiment with them, but I haven't really gotten around to that and had
a fairly embarrassing bug in my code until just now which would have
rendered such experiments useless anyway.

Anyway, the patch is at:
https://codeberg.org/pipcet/emacs/commit/8e28cde297fe0b1a4f8a333e9abee17d76588a7c

> I think the
> lag is related to the `capacity`

I don't know at which point we suspend redisplay to handle further key
presses, I must confess. Can you see whether the behavior is different
for (while t (forward-line 1) (redisplay t)) ?

Pip