Reimer Behrends <behrends / cse.msu.edu> wrote:
=================================================================
> A problem occurs if, say, you have an Image class that allocates memory
> for the pixel data using malloc():

> for i = 1..1000 do
>   img = Image.load(directory + i.to_s + ".png")
> end

> Assuming that each image occupies, say, 1 MB in memory, the program
> allocates roughly 1 GB of memory. Yet as far as Ruby knows, only a few
> kilobytes have been requested, so no garbage collection is initiated
> and the program starts chewing through all the available swap space,
> even though there is plenty of garbage to collect.
=================================================================

The 1 GB memory is a valid memory, isn't it?  So we should not have a
problem with it, unless, of course, our computer does not have that much
of memory.  I just doubt your last sentence above, "even though there is
plenty of garbage to collect".  With GC_MALLOC_LIMIT of 8000000 bytes,
isn't that the maximum garbage to collect is 8 megabytes?

=================================================================
> That may not be a problem with your specific application, but your
> overall argument that ALLOC() can generally be replaced by malloc() does
> not work, because memory may not be freed in a timely fashion. It sort
> of works if the malloced parts are small relative to object size,
> essentially increasing the amount of garbage that can exist in the heap
> by a proportional factor.

> In a nutshell, use of malloc() instead of ALLOC() can break the garbage
> collection heuristic.
=================================================================

I think it is the other way around.  If the garbage collection heuristic
in pure Ruby (without the C extension) already works well, then I think it
is better not to interfere with it.  Well, I guess we are talking about
philosophy here, which is perfecly valid.  The most important thing to
me is that we know the consequence of each of our own choice.

=================================================================
> Your original argument was that Data_Make_Struct() is inherently unsafe;
> but since Data_Wrap_Struct() can trigger a garbage collection as well,
> there should be no difference in kind, just in degree. Efficiency is
> another matter (note also that you may be paying the price of wasted
> memory for fewer collection cycles).
=================================================================

Agreed, in Data_Make_Struct() it is just in degree, not in kind.  However,
execution efficiency is currently of my primary concern.  Because, other
than to interface to existing C library and/or to increase execution
efficiency, why should we write Ruby in C?  Yes, it is impossible to write
the ultimate perfect code in execution efficiency, but at least we are
aware of the issue and consequence.

Thanks for the response.  At least it makes me feel better knowing what I
am doing.

Regards,

Bill