Opened 21 months ago

Last modified 5 days ago

#1650 assigned task

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

Reported by: sjamaan Owned by: sjamaan
Priority: major Milestone: 5.3
Component: core libraries Version: 5.1.0
Keywords: Cc:
Estimated difficulty: medium

Description (last modified by 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.

Change History (8)

comment:1 Changed 21 months ago by sjamaan

Owner: set to sjamaan
Status: newassigned

comment:2 Changed 21 months ago by sjamaan

Description: modified (diff)

comment:3 Changed 21 months ago by sjamaan

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

comment:4 Changed 21 months ago by sjamaan

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

comment:5 Changed 15 months ago by 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.

comment:6 Changed 4 weeks ago by 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)

comment:7 Changed 4 weeks ago by 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.

comment:8 Changed 5 days ago by 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
Note: See TracTickets for help on using tickets.