Hi,

I am sorry that I am having a difficulty in following your reasoning.  For
clarity, I reposted your original Ruby code:

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

First, are we assuming that the "Image.load" has been implemented in C?  I
will assume yes.

Second, why at most 2 out of the 1000 images are accessible at any
time?  What is the intent the Ruby code above?  Does it really have to
load all the images at the same time, or to display one at a time
(basically alloc and free each image in sequence)?  I will assume the
later.

Hmmmm, based on these assumptions, I think you are correct.  The problem
would be my free functions will not be called if they are tied to the
Data_Wrap_Struct (..., ..., free_func, ...) and if the Ruby objects
themselves are indeed small.  Very interesting.  Thanks for the counter
example.  Fortunately, I don't have this kind of peculiarity in my
application.  I will have to note this particular example.  Again, thanks.

Regards,

Bill
=========================================================================
Reimer Behrends <behrends / cse.msu.edu> wrote:
> William Djaja Tjokroaminata (billtj / y.glue.umd.edu) wrote:
>>  Reimer Behrends <behrends / cse.msu.edu> wrote:
> [Loading 1 MB images via malloc.]
>>  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?

> No, 99.8% of the allocated memory is garbage, since at most 2 out of the
> 1000 images are accessible at any time. Ruby only counts memory
> allocated via ALLOC(). It does not even know about malloc(), so its
> internal counter will not be affected by malloc() calls and still be at
> a few K at best (for the ruby objects you have).

> That's why the GC heuristic won't be worth much if you use malloc()
> predominantly.

> [...]

> 			Reimer Behrends