Re: [PATCH 1/2] Prevent excessive major gcs by having decent amount of unused heap

[Sven Hartrumpf]

Hi.

megane wrote, 2021-01-13 12:10:
>
> Sven Hartrumpf <hartrumpf@gmx.net> writes:
>
>> Hi Mario.
>>
> [snip]
>> Run options are:
>>
>> -:hi256m -:H -:hs0 -:o -:s4096k
> The combination of -:hi256m and -:hs0 pretty much guarantees these
> patches won't help you.

I feared so, when I was asked to post my options :-)
I probably added -:hs0 some years ago to avoid heap size yo-yo-ing in a dumb 
way ...;
I will not use it for the next experiments.
I need some -:hi option (only for the new GC!), otherwise it crashes as follows:

  # nallch.x32 -:a0 -:o -:s4096k 0
[panic] out of memory - cannot allocate next heap segment - execution terminated

Even -:hm3900m is not helping (although only 715 MB are reported below),
I must give some -:hi option (any value worked so far, smallest test so far 
-:hi4m):

  # nallch.x32 -:a0 -:hi128m -:o -:s4096k 0

Output from chicken's (time <my-top-level>):

733.251s CPU time, 100.732s GC time (major), 1033919871/121748867 mutations 
(total/tracked), 183/1968864 GCs (major/minor), maximum live heap: 714.99 MiB

> - The first patch would bump the heap size up if your program constantly
>   needed, say 255.99MB of memory (so it'd generate 10k of garbage, run major
>   gc, generate 10k of garbage, run major gc, ...). So, if you've chosen
>   256m conservatively, taking your input data into account, the patches
>   don't help.
> - The second patch is a simple hysteresis control that mitigates rapid
>   heap size yo-yo-ing. Using -:hs0 prevents that completely.
>
> Also, there won't be that much speed-up if the major-gc-time to
> total-run-time ratio is low to begin with.

The ratio was at 35 % on older hardware (esp. slower RAM is causing this high
ratio, I guess) and is now down (on a i9-9900K CPU) to 13.7 %
as calculated from the above output from (time <my-top-level>).

Ciao
Sven