On 11/1/13 1:52 PM, David Bruant wrote: > In any case, I've stopped being against weakrefs after a message by > Mark Miller[...] I am now going to try to convince you that you shouldn't have been convinced by this use case. :)
> To keep the object granularity across machines, in E, they've created > a protocol (CapTP) that, in essence, streches object references across > machines. Cross-machine wrappers if you will. > When designing this protocol, at some point comes the problem of GC. > Distributed GC... First, read Terrence's first response in this thread. This is exactly the kind of use case he is talking about, where GC is used as a general resource-management workhorse. I'm not convinced acyclic distributed GC is a good thing to support. The idea is that by the magic of proxies, remote objects can be made to look exactly like local objects. But then, you can't freely pass a local object as an argument to a remote method. That would create a back edge. The system must either block that with a runtime error or risk a cycle—a silent memory leak on both sides of the boundary. So the boundary is not transparent after all. The transparency doesn’t extend to performance or ease of use anyway. Sidebar: I think general distributed GC (with cycles) is considered Hard. It's been studied. Mark would know better than me. But I think it requires, at a minimum, a lot more cooperation from the GC, including abstraction-busting APIs that we cannot safely expose (like those Gecko's cycle collector uses to trace through the JS heap). E is an incredible body of work. I really can't speak too highly of it; it's amazing. But replicating E is not something I think people want to use JS for. > One use case of cross-vat communication is the remote debugger > protocol implemented in Firefox/OS. This is a really good point. I asked Jim Blandy about this. In the debugger protocol, when you hit a breakpoint or debugger-statement, that creates a "pause actor" in the protocol. Actors form a tree. Just about everything you encounter while inspecting a paused debuggee is parented by the pause actor. When you tell the debuggee to continue, the pause actor and all its descendents are released (with a single protocol request). The protocol lets you explicitly promote a reference to some debuggee object from "pause lifetime" to "thread lifetime", but we don't currently have any code that uses that feature. So as far as I know it is *impossible* for the debugger to be leaking stuff beyond the next time you hit the Continue button! This supports your contention that good API design achieves better results. If we had implemented some complicated distributed GC scheme with weak references, it would be possible to leak things in the debuggee simply by accidentally stashing a closure somewhere that closes over some reference that we wish would be collected. Instead, we have done something simple, so we can grep the code and see that there are no leaks. IPDL does something similar. Objects that can be referenced across the process boundary form explicit hierarchies; when one is freed, its descendents are also freed. -j _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
