William Djaja Tjokroaminata (billtj / y.glue.umd.edu) wrote:
[...]
>  1) When Ruby memory is dynamic, we don't need to use ALLOC to free memory
>  periodically, because the garbage collector is already being called
>  often by Ruby internals.  If we use ALLOC, then the garbage collector is
>  called even more often, which may result in execution performance
>  degradation.

This is inaccurate. Ruby only knows about the memory allocated via
ALLOC(), not of memory allocated via malloc(). So, Ruby's heuristic
as to when to start the next GC might be way off, and you might
use more physical memory than necessary. In the extreme case, Ruby
would not start garbage collecting before you run out of swap space.

>  2) When Ruby memory is static, there is no real need to invoke the garbage
>  collector.  If we use ALLOC, then the garbage collecting is only an
>  execution waste, because no new memory will actually be released.

Once memory has become static, there will be no more calls to the
garbage collector; hence no CPU overhead from the garbage collector,
either.

>  So, it seems that we should always use malloc (or its safe
>  version) instead of ALLOC.  What is the flaw in the above
>  argument?  (Sorry, plain response such as "it is stupid" is not
>  acceptable.)

A big flaw in your argument is that you assume that you can always take
over the duties of freeing memory yourself. That works if the allocated
memory is referenced only by a single object. If the reference gets
passed around, you'll essentially find that you're implementing memory
management yourself again, trying to find out if the malloc()ed memory
is still accessible.

>  If the above argument is accepted, then because Data_Make_Struct calls
>  ALLOC explicitly, it also follows that Data_Wrap_Struct should be
>  preferred to Data_Make_Struct.

Note that Data_Wrap_Struct() can initiate garbage collection as well,
namely in rb_newobj(). It doesn't really make a difference.

			Reimer Behrends