From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-08-22T22:15:20+09:00
Subject: Re: Amortized cost of garbage collection

Thanks a lot, Mauricio, for the comprehensive treatment of the
subject.  It is very good to know what is going on in the background and  
it can be used to influence the design decision, especially when execution
performance is the objective.  It just surprised me that at the most basic
level Ruby calls malloc() and free() directly instead of managing its own
memory arena.

Regards,

Bill

=========================================================================
Mauricio Fern?ndez <batsman.geo@yahoo.com> wrote:
> (deleted)

> d could be made smaller than c (which involves recursion or pointer
> reversal) if you didn't care about memory fragmentation (it would only
> involve updating a linked list), but as Ruby uses malloc instead of
> managing its own arena, freeing the memory will probably be costlier
> on the average. In fact in the book I mostly took this from, they gave
> c = 10 ins. and d = 3 for "some computer", but without taking care of memory
> fragmentation. (R and H given in words)
> Anyway it isn't very fair to consider the cost of free() as you'd have
> to do it if you sticked to malloc()/free().

> This is another area where being able to define Ruby's behavior would be
> great for some tasks, going even further in the mem/speed tradeoff than
> malloc...

> (deleted)