Re: [Chicken-hackers] GC and heap growth percentage question

[Peter Bex]

On Sun, Jun 24, 2012 at 01:44:18PM +0200, Felix wrote:
> > IIUC, this means that whenever more stuff is allocated between two GCs
> > (old heap + stack?) than twice the heap, it will fail.  I'm not sure yet
> > how this situation would happen, but there are a lot of places which hold
> > values that are remarked, so I can imagine there could be situations
> > where these taken together are more than twice the current heap.
> 
> This would mean either the nursery is bigger than one half of the new
> space (very unlikely) or that data is copied more than once (which
> would be a bug).

Interesting.

> >> You can try using a fixed heap (say, using "-:h500m") - does that make
> >> a difference? (the test seems to run ok on my machine).
> > 
> > Yes, it does not give any error with -:h500m, just like when I pass
> > -:hg250 or higher.
> 
> What happens when you use different settings for "-:f"?

Using -:f4000 or higher makes the OOM error go away.

> Is this only finalizer-error-test that fails?

Yes

> Are you sure you are building it with the correct compiler?

Yeah, I rebuilt a few times.

> Have you bootstrapped recently? Are you not
> mixing up different runtime library versions?

I've just created a new bootstrapping compiler and recompiled
the Chicken I'm testing with, and get the same behavior (OOM crash
in tests/finalizer-error-test).  I also tried fetching a clean 4.7.4
dev snapshot and building from there.  Same thing.
By the way, by doing a completely clean build I found out that
runtest.sh contains a call to the test, but the test itself isn't
in the git repo(!)

If you'd like, you could test it yourself on my amd64 box.
It may have something to do with the architecture or operating system
(or maybe ulimit settings since that involves stack size, which
probably influences this too).

My current ulimit looks like this:
$ ulimit -a
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     8388608
-s: stack size (kbytes)        131072
-c: core file size (blocks)    0
-m: resident set size (kbytes) 1984148
-l: locked-in-memory size (kb) 1984148
-u: processes                  1044
-n: file descriptors           3404
-N  9: socket buffer size (kb) unlimited
-v: virtual memory size (kb)   unlimited

The other box I tried this on (same arch, slightly different NetBSD
version) has the same settings except the stack size is 32768

I just got confirmation from Megane on IRC that the original program
that triggered the bug works with a patched Chicken that corresponds
to today's master (I know, sorry; I asked to test it with the actual
master half an hour ago but got no reply).  The finalizer-test is just
a simplified version of that program.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth