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!
>