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

[Sven Hartrumpf]

Hello.

I wrote, 2021-01-13 22:24:
> 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

I have experimented some more (with x32 binaries).
I am now running my binary with:

-:a0 -:hiNNNm -:hm3900m -:o -:s4096k

Then, I tried several values NNN for -:hiNNNm.
crashes: 2 6 7 8 16
ok: 3 4 5

I added (set-gc-report! #t) and attach a complete log from a crashing run with 
NNN=6.

Ciao
Sven

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

ch-crash.log.zst
Description: Binary data