On 11/02/2013 10:24 AM, Allen Wirfs-Brock wrote: > > 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.
Thank you! That was exactly what I wanted to express, only with greater pith and fewer words. > 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 > _______________________________________________ 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
