On Nov 1, 2013, at 3:17 PM, Jason Orendorff wrote: > 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.
My experience is that Terrence is absolutely correct in this regard and that this position is share by virtually all experienced GC implementors. A former colleague of mine, George Bosworth, expressed it this way in an experience report at a ISMM a number of years ago: A modern GC is a heuristics-based resource manager. The resources it manages generally have very low individual value (a few dozen bytes of memory) and exist is vast numbers. There is a wide distribution of life-times of these resources, but the majority are highly ephemeral. The average latency of resource recovery is important but the recovery latency of any individual resource is generally unimportant. The heuristics of a great GC take all of these characteristics into accounts. When you piggy-back upon a GC (via finalization, or equivalent mechanism) the management of a different kind of resource you are applying the heuristic of memory resource manegment to the management of the piggy-backed resources. This is typically a poor fit. For example, the piggy-backed resource may be of high individual value and exist in limited numbers (George's used file descriptors as an example). A good GC will be a bad resource manager for such resources. There are many types of resources that need to be managed in complex systems. Thinking that a GC will serve as a good management foundation for most of those resources is just naive. I previously made some other comments that relate to this issue at http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#allen_wirfs-brock_20111219 In particular, see the "backstop" discussion. > > 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). Yes, indeed. And there is a lot of experience that fully transparent distributed object graphs are not a very good idea. The dream was that an application could ignore distribution boundaries. In practice you always want to know when you are about to traverse a highly latency reference rather than a normal essentially 0 latency reference. Allen _______________________________________________ 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
