Re: Garbage collection and define_finalizer

On Wed, Nov 30, 2011 at 4:11 AM, Garthy D
<[e-mail]> wrote:

> Thankyou for the detailed reply. :)

You're welcome!

> On 30/11/11 00:07, Robert Klemme wrote:
>>
>> On Tue, Nov 29, 2011 at 1:43 PM, Garthy D
>> <[e-mail]> rote:

>> What you observe might mean that you
>> simply haven't created enough Ruby garbage for GC to think it needs to
>> work.  have no idea how you allocate texture memory but if it is in
>> a C extension written by you I would check whether there is a way to
>> go through MRI's allocation in order to correct MRI's idea of used
>> memory. mplementation of Ruby's String might be a good example for
>> that.
>
> Your assumption re the C extension for texture memory is pretty-much spot
> on. :)

:-)

> Re texture memory, it's a little more complicated than a standard
> allocation. Some memory will be the standard allocated sort, but some will
> be on the video card, and they're effectively coming from different "pools"
> (or heaps), neither of which I'll have direct control over. Unless the Ruby
> GC directly understands this concept (I don't know if it does, but I'm
> guessing not), I'm not going to be able to use Ruby to manage that memory.
> Unfortunately, the problem goes a bit beyond just textures, as I'm wrapping
> a good chunk of a 3D engine in Ruby objects. That's my problem to worry
> about though.

Sounds tricky indeed.

> And that's assuming I can redirect the allocation calls anyway- I'm not sure
> if I can. It'd be nice to be able to inform the Ruby GC of allocated memory
> (or an estimate, if it keeps changing) without actually leaving the GC to
> allocate it. Please correct me if I'm wrong, but I'm assuming this can't be
> done, and you must use the ALLOC/ALLOC_N-style functions?

I'm not such a good source for this as the source (or Matz).  So you
probably better look elsewhere for a definitive answer.  Maybe for
your issue it is sufficient to just reduce the threshold from which on
Ruby starts considering GC at all.  I can't really tell.

> Unfortunately it causes a lot of problems in my case, as I had assumed one
> thing from general reading on the topic, and observed another. That's my
> problem to deal with though, not anyone else's. Still, there seems to be lot
> of information online that talks about Ruby performing mark and sweep,
> either stating outright that unreferenced objects are freed on first GC, or
> heavily implying it at least. From your description, and my observations,
> this information appears to be incorrect. Basically, there seems to be a lot
> of misinformation about what the GC is doing. Apart from the source, is
> there some place where the correct behaviour is discussed, that could be
> referred to instead, particularly if someone is suggesting that the MRI GC
> implementation should immediately clean up these references on next GC
> (which, as we've established, isn't accurate)?

I am not aware of any.  I haven't searched extensively though.  But we
might need to update locations you found to reflect the truth.
Ideally someone from core team would do a writeup which explains how
GC works - at least for MRI.  Chances are also that behavior has
changed between 1.8 and 1.9 as these are quite different internally.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/