[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] Heap size calculation in rereclaim2
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] Heap size calculation in rereclaim2 |
Date: |
Wed, 14 Oct 2015 09:43:59 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
(looks like you accidentally hit reply instead of reply all/reply to list)
On Tue, Oct 13, 2015 at 11:06:58PM +0200, address@hidden wrote:
> > Am I correct in thinking that double_plus is misnamed and should really
> > be called "relative_size" or something? Felix: Do you remember the
> > original meaning of these two parameters, how are they to be used?
>
> I'm not sure. Double_plus is intended to enlarge the heap (by doubling it),
> and add the required size. But it may very well be the case that by the
> subsequent
> halving (for the two heap spaces), the "doubling" gets lost. Your description
> of the bug seems plausible, but shouldn't this have caused problems before?
I think the reason it hasn't caused problems before is because it's
kind of rare to allocate literals that are more than the current heap
size. And my guess is that most large literals are strings or blobs (or
srfi-4 vectors which are internally blobs). These do not trigger this
problem due to the fact that they're allocated with malloc().
Initially I thought it wasn't likely that this is the cause of the
problem we are seeing on Salmonella, but then it hit me that this
triggers a major GC, which also will copy the nursery. The change
we made to re-use argvectors causes the stack to accumulate more slowly
so there will be more actual Scheme data on it, which could mean that
when you load a toplevel, there's more stuff that gets copied into the
heap, meaning the data to be allocated by the toplevel might not fit
anymore.
Cheers,
Peter
signature.asc
Description: Digital signature