[plt-scheme] bytes 'n bits 'n pieces

Excellent, that's now crystal clear. Thanks!

-- Éric


On Apr 30, 2009, at 16:39 , Matthew Flatt wrote:

> At Thu, 30 Apr 2009 16:29:05 -0400, Eric Tanter wrote:
>> . what is the actual size of an allocated object? (empty objects with
>> either no fields or a single next object reference)
>
> The GC adds a 1-word overhead to every allocated object. A Scheme  
> value
> also always has a tag, which adds another word. (There are a lot of
> otherwise unused bits in those two words that get used for hash  
> codes.)
> Finally, on most platforms, the GC rounds all object sizes up to a
> multiple of 8.
>
>> . since I also want to be able to evaluate how much memory a given
>> list will occupy, how much does a cons cell use?
>
> 4 words, of which 1 word is GC overhead and 1 word is tagging  
> overhead.
>
>> I noticed that even with 768MB I can't create a list (in a tail
>> recursive manner of course) of 100,000,000 elements (element = null).
>
> On a 32-bit platform, a list that long should consume about 1.6GB.
>
> A list of 10,000,000 items will use about 160MB. To build the list,  
> the
> GC will push actual memory use up two around 300MB, since collections
> are triggered roughly when memory use is twice as large as since the
> most recent collection.
>