2009/12/22 Wayne Meissner <wmeissner@gmail.com>:

>  # s can now be collected, the backing memory proxy can be collected,
> which will free the
>  # allocated native memory.

I should have added a footnote that just because it *can* be
collected, there is in fact no guarantee that objects are in fact ever
collected by the GC.  Depending on the implementation, there might not
be sufficient ruby/java memory pressure to cause a GC event, so the
objects are not collected, and the native memory is never freed.

Automated management of native memory is a no-win situation:

If we have it in FFI core, then people will (ab)use it and rely on it
when they really should not.

If we do not have it in core, people will implement them anyway, and
instead of a single known implementation,  there will be a dozen
crappy, broken implementations of the concept, and people will still
abuse these implementations and rely upon them when they should not.

MemoryPointer and AutoPointer are in FFI core because I thought that
was the lesser of two evils.

(and, most instances are small and short lived, so there is enough
object churn to cause a GC event, so the negative effects haven't
massively bitten anyone).

In hindsight, I would probably have just two types of memory - purely
passive native pointers, and ruby heap allocated memory with
copy-in/copy-out to transient native memory semantics.  Structs would
implicitly use the ruby heap memory, unless an explicit native pointer
was passed to the constructor.

People should peruse e.g. the nokogiri FFI backend, and figure out how
one would rewrite it with explicit memory management, before proposing
solutions to the problem.