Empty program will sometimes do a major GC, sometimes not - figure out why

[sjamaan]

This is an interesting thing to figure out

If you compile a completely empty file, and run it with -:g, sometimes it will do a major GC and sometimes it won't (just run it a few times, you'll notice the output is different sometimes).

Also, the major GC count is always at least 1.

This might also contribute to the instability of our benchmark results.

[sjamaan]

After some playing around with -explicit-use, it seems that the modules unit is responsible for this (or perhaps its dependency chain).

[sjamaan]

Sometimes this doesn't happen at all. Very frustrating!

[felix winkelmann]

I can not reproduce this on my OpenBSD machine - it would be interesting to actually see the output of -:g here and on what environment it runs.

Note that a major GC is performed after the program has executed, shortly before termination to run any pending finalizers.

[sjamaan]

Here's a log of a quick test I did just now, showing how random it really is:

$ ~/chickens/chicken-5/bin/csc -version
CHICKEN
(c) 2008-2021, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.1 (rev 01b254c2)
linux-unix-gnu-x86-64 [ 64bit dload ptables ]
$ ~/chickens/chicken-5/bin/csc empty.scm
$ ./empty -:g
$ ./empty -:g
[GC] Heap high water mark hit, growing...
[GC] (old) fromspace:   start=0x00007f67500ef010,       limit=0x00007f675016f010
[GC] (old) tospace:     start=0x00007f675006e010,       limit=0x00007f67500ee010
[GC] resized heap to 3145728 bytes
[GC] (new) fromspace:   start=0x00007f674feed010,       limit=0x00007f675006d010
[GC] (new) tospace:     start=0x00007f674fd6c010,       limit=0x00007f674feec010
[GC] level  1   gcs(minor)  0   gcs(major)  1
[GC] stack      0x00007ffe554e15d0      0x00000000554e1dd0      0x00007ffe555e15d0
[GC]  from      0x00007f674feed010      0x00007f674ff26188      0x00007f675006d010      0x0000000000039178
[GC]    to      0x00007f674fd6c010      0x00007f674fd6c010      0x00007f674feec010 
[GC] 0 locatives (from 32)
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
$ ./empty -:g
[GC] Heap high water mark hit, growing...
[GC] (old) fromspace:   start=0x00007fd665f77010,       limit=0x00007fd665ff7010
[GC] (old) tospace:     start=0x00007fd665ef6010,       limit=0x00007fd665f76010
[GC] resized heap to 3145728 bytes
[GC] (new) fromspace:   start=0x00007fd665d75010,       limit=0x00007fd665ef5010
[GC] (new) tospace:     start=0x00007fd665bf4010,       limit=0x00007fd665d74010
[GC] level  1   gcs(minor)  0   gcs(major)  1
[GC] stack      0x00007fff47ec3780      0x0000000047ec3940      0x00007fff47fc3780
[GC]  from      0x00007fd665d75010      0x00007fd665dae188      0x00007fd665ef5010      0x0000000000039178
[GC]    to      0x00007fd665bf4010      0x00007fd665bf4010      0x00007fd665d74010 
[GC] 0 locatives (from 32)

[sjamaan]

If I run this with 5.1.0 or 5.2.0, I get similar results, but one or two instead of zero or one GCs (progress, I suppose...). This change is probably due to some of the GC patches by Megane. But the overall randomness is the same.

[megane]

This randomness can be fixed by changing the line
srand(C_fix(time(NULL))); in runtime.c to

• srand(C_fix(42)); for no GC, or
• srand(C_fix(424242)); for always GC.

You can test with this:

for i in `seq 30`; do
    echo "---------------- $i"
    sleep 1
    for j in `seq 5`; do
        ./empty -:g |& grep resized || true
    done
done

A run without the "fixes":
---------------- 1
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
---------------- 2
---------------- 3
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
---------------- 4
---------------- 5
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
---------------- 6
---------------- 7
---------------- 8
---------------- 9
---------------- 10
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes
[GC] resized heap to 3145728 bytes

[Mario Domenech Goulart]

The patch submitted by Peter in ​https://lists.nongnu.org/archive/html/chicken-hackers/2021-06/msg00002.html has been pushed to master (a65ce731).