I'll address the biggest hole in this here. FFI::MemoryPointer, FFI::Struct, and FFI::ManagedStruct are all proxy objects. Nothing they reference lives in the ruby heap. This is the only way they can be implemented by all implementations because the API must be able to provide struct style access on pointers returned by any function. That means that the storage for the memory being referenced is outside the control of ruby entirely.

When a ruby GC detects that an FFI::Struct is garbage, the memory that the FFI::Struct references is acted upon at all. This is because FFI::Struct is just a proxy for some unmanaged memory.

 - Evan

On Dec 21, 2009, at 12:26 PM, Jon wrote:

> Before I add API-ish level doc to http://wiki.github.com/ffi/ffi/structs please double check my FFI::Struct and FFI::ManagedStruct understanding.  Please ensure feedback is valid across the impl's.
> 
> 1) Both FFI::Struct and FFI::ManagedStruct are able to be freed by the Ruby impl's GC. Overall GC semantics are no different that any other Ruby object GC'd by the specific Ruby impl.
> 
> 2) FFI::ManagedStruct enables one to specify custom cleanup code via a required 'release(ptr)' class method that is guaranteed to be called only once when the instance is GC'd.
> 
> 3) Neither FFI::Struct nor FFI::ManagedStruct currently provide for deterministic GC-ing (is it valid to call FFI::MemoryPointer#free deterministic GC??)
> 
> 4) FFI::Struct and FFI::ManagedStruct instances live completely in Ruby heap memory.  Or are they effectively proxy objects in Ruby heap that interface and manage their underlying native heap-based structs? This one's likely too impl specific to put in the wiki docs, but I'm still curious :) 
> 
> Thanks, Jon
>