CHICKEN Scheme

Summary

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

Metadata

Id: d93ef1a5b283e7f49c7454eec1dcdb7d8efdcb72
Trac id: 1650
Type: task
Reporter: sjamaan
Owner: sjamaan
Cc:
Status: closed
Component: core libraries
Estimated difficulty: medium
Resolution: fixed
Priority: major
Milestone: 5.3
Version: 5.1.0
Changetime: 2021-06-23 22:08:34 UTC
Created: 2019-09-28 15:48:40 UTC
Keywords:

Description

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.

Changes and comments

[2019-09-28 15:48:49 UTC] sjamaan changed status from new to assigned

[2019-09-28 15:48:49 UTC] sjamaan set owner to sjamaan

[2019-09-28 15:49:37 UTC] sjamaan changed description

[2019-09-28 15:55:38 UTC] sjamaan wrote:

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

[2019-10-06 14:55:29 UTC] sjamaan wrote:

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

[2020-03-26 14:00:03 UTC] felix wrote:

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.

[2021-05-21 14:16:26 UTC] sjamaan wrote:

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)

[2021-05-21 14:18:39 UTC] sjamaan wrote:

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.

[2021-06-16 20:03:18 UTC] megane wrote:

This randomness can be fixed by changing the line

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