On Wed, Jun 27, 2012 at 08:18:37PM +0200, Peter Bex wrote: > I think the patch is a stab in the right direction, but that calculation is > not near precise enough. The bug can be triggered more easily by passing a > low heap growth percentage, for example: > > ./test/finalizer-error-test.scm -:hg110
After discussing this with Felix I came to the conclusion that the mutation stack is a distraction from the real issue, which is that the heap size must grow at least enough to contain all the objects from the nursery. The attached patch simply checks that at least the nursery size is added to the current heap size. The default heap size is also changed to be equal to the default nursery size. This means each initial major GC can be postponed a little while longer. This should speed up most programs because the heap won't be way too small like now. The patch also tweaks the test to run with a VERY small heap growth (so it includes the patch I posted previously) There's still something slightly wrong because in abnormal situations like setting the heap growth to 90%, which actually would be *shrinking* instead of growing, the test still fails with an OOM error, which shouldn't happen because this patch ensures the heap will grow at least enough to accommodate the current heap plus the nursery. I'm not sure it's worth worrying about this since a negative growth factor is clearly bogus and we can declare that a case of "garbage in, garbage out", but in extreme cases where the nursery is very small this might cause the bug to reappear. 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
>From 383bc095a5784954e4b98ea26cc904ec7460e665 Mon Sep 17 00:00:00 2001 From: Peter Bex <[email protected]> Date: Sat, 30 Jun 2012 12:46:33 +0200 Subject: [PATCH] When resizing the heap ensure it grows enough to accommodate the nursery. This fixes out of memory errors in extreme cases like allocating finalizers on lots of objects in a tight loop --- runtime.c | 7 +++++-- tests/runtests.bat | 4 ++++ tests/runtests.sh | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/runtime.c b/runtime.c index b0ccc85..04d476f 100644 --- a/runtime.c +++ b/runtime.c @@ -139,8 +139,8 @@ extern void _C_do_apply_hack(void *proc, C_word *args, int count) C_noret; #endif #define DEFAULT_SYMBOL_TABLE_SIZE 2999 -#define DEFAULT_HEAP_SIZE 500000 -#define MINIMAL_HEAP_SIZE 500000 +#define DEFAULT_HEAP_SIZE DEFAULT_STACK_SIZE +#define MINIMAL_HEAP_SIZE DEFAULT_STACK_SIZE #define DEFAULT_MAXIMAL_HEAP_SIZE 0x7ffffff0 #define DEFAULT_HEAP_GROWTH 200 #define DEFAULT_HEAP_SHRINKAGE 50 @@ -3120,6 +3120,9 @@ C_regparm void C_fcall C_rereclaim2(C_uword size, int double_plus) if(size < MINIMAL_HEAP_SIZE) size = MINIMAL_HEAP_SIZE; + /* Heap must at least grow enough to accommodate first generation (nursery) */ + if(size - heap_size < stack_size) size = heap_size + stack_size; + if(size > C_maximal_heap_size) size = C_maximal_heap_size; if(size == heap_size) return; diff --git a/tests/runtests.bat b/tests/runtests.bat index 93efb4d..753257a 100644 --- a/tests/runtests.bat +++ b/tests/runtests.bat @@ -400,6 +400,10 @@ echo ======================================== finalizer tests ... if errorlevel 1 exit /b 1 echo ======================================== finalizer tests (2) ... +%compile% finalizer-error-test.scm +if errorlevel 1 exit /b 1 +a.out -:hg101 +if errorlevel 1 exit /b 1 %compile% test-finalizers-2.scm if errorlevel 1 exit /b 1 a.out diff --git a/tests/runtests.sh b/tests/runtests.sh index a87d750..093115c 100755 --- a/tests/runtests.sh +++ b/tests/runtests.sh @@ -348,7 +348,7 @@ $compile symbolgc-tests.scm echo "======================================== finalizer tests ..." $interpret -s test-finalizers.scm $compile finalizer-error-test.scm -./a.out +./a.out -:hg101 $compile test-finalizers-2.scm ./a.out -- 1.7.9.1
_______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
