Ahh... damn!
I was completely aware of that problem when defining finalizers and I thought I had avoided it by having a class-method call ObjectSpace.define_finalizer but I didn't realized that self was still being closured =\

Thanks a lot!
It actually seems that the finalizer is called when doing GC.start after all.

I guess everyone can ignore my big rant on the previous posts =b.

Matt

On 05/05/2010 09:09 PM, Evan Phoenix wrote:

You have hit on the #1 problem with ruby's finalizer API. You've referenced the object you want to finalize with the closure for finalizing it, thus preventing it from ever being collected.

AutoPointer provides an API to do this exact thing, you're better of using that than trying to use finalizers directly.

If you must use a finalizer, here is what you should do instead

def Vector.create_finalizer(ptr)
    lambda { |id| GSLng.backend.gsl_free_vector(ptr) }
end

def Vector.define_finalizer(self, ptr)
    ObjectSpace.define_finalizer(self, create_finalizer(ptr))
end

  - Evan

On May 5, 2010, at 3:56 PM, v01d wrote:

Hi,
I'm in the process of developing a Ruby binding to the GSL numerical
library using FFI. Recently I stumbled upon a problematic issue
regarding memory management and finalizers.

Since the GSL library allows creation and destruction of instances
like this:
gsl_vector* ptr = gsl_alloc_vector(size_t n);
...
gsl_free_vector(ptr);

Then, in Ruby I do something like this:

class Vector
  def initialize(n)
    @ptr = GSLng.backend.gsl_alloc_vector(n)
    Vector.define_finalizer(self, @ptr)
  end

  def Vector.define_finalizer(self, ptr)
    ObjectSpace.define_finalizer(self, lambda {|id|
GSLng.backend.gsl_free_vector(ptr)})
  end
end

The problem is that if later I instatiante a Vector inside a loop,
like:
10000.times do
  Vector.new(3)
end

This obviously eats a lot of memory until GC runs. Now, if I do:
10000.times do
  Vector.new(3)
  GC.start
end

the memory that the Vector instances themselves occupy is freed but
the finalizer is not called (it is later called at program end),
therefore all of the memory allocated through gsl_alloc_vector() is
sitting there until program ends.

I know that Ruby doesn't guarantee that finalizers are called in any
particular moment (even after GC.start, which I thought would
suffice). So what I'm asking probably is not really related to FFI
itself, but I wanted to ask here since I imagined this would be a
common pattern among FFI users. The question is then: is there a
better way to manage this type of memory? I obviously cant use the
transaction-like pattern (like File.open) since for a Vector that
wouldn't make sense. It would be ideal to make the gsl_vector_free
call when the actual Vector class is free'd. Maybe I need to go to a
lower level for this and use the C api to register this call in the
"free" function for this class, but that would be overkill since I
wanted to avoid using C altogether.

Thank you!