On Aug 26, 2014, at 18:53 , Marvin Humphrey <[email protected]> wrote: > On Wed, Aug 20, 2014 at 2:22 PM, Nick Wellnhofer <[email protected]> wrote: >> On Aug 19, 2014, at 19:52 , Marvin Humphrey <[email protected]> wrote: >> >>> * Tracing GC (Ruby, Go) >> >> I’ve also been thinking about this. It should be feasible if we keep track >> of all Clownfish objects that were passed to the host language. > > The crucial feature is adding instance data to user-defined subclasses using > standard host idioms. > > Under tracing GC, we can always fall back to incrementing the refcount each > time we create a host object wrapper and decrementing the refcount each time a > host finalizer fires. However, that approach is not compatible with adding > instance data to host subclasses, since the lifespan of such instance data > would be tied to the lifespan of a host wrapper -- not the inner Clownfish > object.
If we keep a list of all Clownfish objects passed to the host language, we could implement a “mark” function that runs through that list and marks all objects still referenced from C space. Then the host finalizer would only fire when there are no references from either host or C space and the object can be destroyed. This comes at some cost, but I don’t think it’s prohibitive. What we definitely want to avoid is forcing Clownfish classes to implement their own mark method. > BTW, it occurs to me that instead of requiring Perl users to use inside-out > fields, we could enable hashref overloading one every Clownfish > object similar to how we have it on Lucy::Document::Doc. That would be nice. >> I don’t know anything about how Go interfaces with C, but I can imagine that >> the lack of virtual methods in Go poses an interesting problem. > > The main challenge is that the Go developers want to write a maximally > efficient compacting copying collector, and that makes it hard to give access > to Go objects from C-space. > > http://golang.org/issue/8310 > > We need some way to prevent Go pointers from crossing the boundary into C. > > It's interesting to note that the insular approach explored in that ticket > and Clownfish-style symbiosis are nearly antithetical. This is interesting, but it affects all extension authors. I guess that the Go developers will have to provide some way to keep references to Go objects from C space. Otherwise, it would be extremely hard to write certain kinds of extensions. Nick
