[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix #1058 and (hopefully) #1045

From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Fix #1058 and (hopefully) #1045
Date: Mon, 14 Oct 2013 22:17:50 +0200
User-agent: Mutt/

On Sun, Oct 13, 2013 at 01:51:01PM +0200, Peter Bex wrote:
> After adding these checks, I noticed that in a DEBUGBUILD, the
> hash-table tests started failing consistently with the dreaded
> "out of memory - heap full while resizing" error.  After spending the
> weekend groveling through the garbage collector, I finally found a
> very strange statement in runtime.c: after carefully calculating
> the new heap size and ensuring it will fit both the current heap
> and the stack, the heap size is HALVED, for no apparent reason!
> There isn't even a comment stating why this is done.

I went and asked our tribal elder, and he explained to me that the
rereclaim function's size calculation is based on the FULL heap size,
which consists of two halves: fromspace and tospace.

This means that the fix of removing the line that divided the
size by two would effectively cause the heap to grow by 200% instead
of 100% in the usual case.  This also suggests the correct fix: to
change the code that ensures the heap is at least its current size plus
enough room to accommodate what's on the stack such that it will add
twice the stack size (because it will be tacked onto both the tospace
and the fromspace).

So here's the three patches again, with some additional comments in the
GC for total clarity, so we will never get confused about this again!


Attachment: 0001-Add-paranoid-checks-to-C_u_i_car-and-C_u_i_cdr.patch
Description: Text document

Attachment: 0002-Fix-1058-never-add-mutex-objects-to-FD-lists-in-the-.patch
Description: Text document

Attachment: 0003-Hopefully-fix-1045-by-growing-both-halves-of-the-hea.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]