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