On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller <[email protected]> wrote: > On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff <[email protected]> >> JS users do not want RPC systems where one process's memory usage >> depends on getting per-object callbacks from an untrusted peer's GC >> implementation. > > Some will. I do. See <http://research.google.com/pubs/pub40673.html>.
OK, but let's stick to use cases and examples outside your own research. > Why do you believe manual deallocation decisions will be easier in > distributed systems than they are locally? I don't. That's why I cited several examples of systems that require neither fine-grained manual deallocation nor distributed GC. > You are correct that a distributed mutually suspicious system must support > manual deallocation as well. Your Erlang example is quite telling: Erlang > does have strong cross process references, the process id. However, because > they are forgeable, processes cannot be garbage collected. The decision to > terminate a process is the decision to preemptively terminate service to > clients that may still exist. Sometimes this needs to be done, even with GC, > because the client causes the service to retain more memory than the service > wishes to continue to devote to this client. [...] Hmm. I don't really disagree with any of this, except the notion of pids being strong references, and I think my point stands. Erlang has no distributed GC, no weak references of the sort we're discussing, and (I still claim) no strong cross-process references. Yet its users don't seem to have any of the problems that acyclic distributed GC is supposed to solve. > However, many clients will engage in honest GC to keep their requirements on > service memory low. Many services will not need to cut such clients off > because of excessive resource demands. Perhaps, but they still need to cut off bad clients, and even honest clients in this kind of system can inadvertently hog server resources simply by not doing GC for a while (because, for example, there isn't memory pressure *on the client*). In these cases I'm not sure how the server can tell which clients to cut off. It seems like it would require automation of the sort of memory tooling you characterized as experimental earlier in this thread. Even if it all that works out, we're still left with an abundance of widely used alternative designs, the high total cost of implementing weak references, the nondeterminism they introduce, the security consequences, and so on. -j _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
