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

While these proxy objects live in the ruby heap and are subject to the will of the specific ruby impls gc, the real goodies are always in the native heap.  Got it, thanks.

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

You mean the unmanaged mem is *not* acted upon at all (typo) right?

Are you also saying that if the proxy object is ruby GC'd the unmanaged mem is (currently) never freed by any of the impls?

So while we should never see the dangling pointer class of issues, do you see real-world potential for writing ruby ffi code that can easily leak memory?  For example, if I'm creating/destroying FFI::Struct proxies in a callback in some long-lived process, the ruby heap will be cleaned but the underlying unmanaged mem in the native heap would not be?

Jon