Re: [Chicken-hackers] Heap size calculation in rereclaim2

[Jörg F. Wittenberger]

Am 14.10.2015 um 09:43 schrieb Peter Bex:
> (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.

I'm not so sure.  I had problems with chicken running out of memory upon
startup years ago.  (Which I eventually worked around by triggering
additional gc's.  I might try to figure the details out later if needed.)

>  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().

Wait - when are those blobs/strings allocated with malloc()?  I know
it's possible if explicitly requested.  But I rarely ever did so.

Otherwise I did abuse strings to binary data of several 10 MB, assuming
this would overwhelm the GC.  Was surprised it did not.

So if there's magic to automagically switch to malloc() for huge
blobs/string than forget this message.  Otherwise your guess may be wrong.

Best

/Jörg

signature.asc
Description: OpenPGP digital signature