domenic at domenicdenicola.com (2013-11-17T17:57:06.591Z)
On Mon, Nov 11, 2013 at 1:09 PM, Jason Orendorff <jason.orendorff at gmail.com>wrote: > OK, but let's stick to use cases and examples outside your own research. - Much of the early Actors research - DEC SRC Network Objects - RMI - Original-E before I arrived at Electric Communities - Midori - Orleans - AmbientTalk - Cap'n Proto Much of the early Actors research did cyclic GC as well, but this early distribibuted GC work notably violated the general Actors assumption of mutual suspicion. Original-E is the only system I know to do full distributed cyclic GC among mutually suspicious machines http://www.erights.org/history/original-e/dgc/index.html. I specify "before I arrived at Electric Communities" because of your requested constraint, and because the secure distributed cyclic GC was already working then. Cap'n Proto is designed primarily for the local C++ bindings. It has the distributed acyclic GC logic I explain, but typically driven by local manual deallocation rather than local GC and finalization. I am not confident of the GC properties of Midori and Orleans. If someone knowledgeable of these systems would comment, that would be great. > > 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. I didn't say "fine-grained". Erlang requires manual deallocation of processes. Also, you did specify "untrusted". Distributed Erlang does not qualify, exactly because pid are forgeable. > Hmm. I don't really disagree with any of this, except the notion of > pids being strong references, and I think my point stands. What do you mean then by "strong reference"? If Erlang pids are not strong references, then I don't understand what you are saying. > 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. How do they choose when to kill a process? > 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. That's fair. Driving distributed GC by observing local GC has exactly the problem you point out: As we give one vat more memory, reducing its memory pressure, it observes far fewer finalizations, increasing the memory pressure on its counter-party vats. Perhaps the reason this problem hasn't been too pressing in the past is that none of our vats had enough local memory to cause the problem. > 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. What "abundance of widely used alternative designs" do you mean? Of distributed object systems and distributed GC protocols? Sure. I am not proposing to standardize any of these until they've obtained more usage in JS. Of weakref / post-mortem finalization ideas? I think the design space or the remaining controversies here are small compared to many of the other issues that TC39 has been able to converge on. And until we have that, we can't get started on the distributed GC cowpaths we need to move forward on full distributed objects for JS.
On Mon, Nov 11, 2013 at 1:09 PM, Jason Orendorff <jason.orendorff at gmail.com>wrote: > On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller <erights at google.com> > wrote: > > On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff < > jason.orendorff at gmail.com> > >> 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. > Much of the early Actors research DEC SRC Network Objects RMI Original-E before I arrived at Electric Communities Midori Orleans AmbientTalk Cap'n Proto Much of the early Actors research did cyclic GC as well, but this early distribibuted GC work notably violated the general Actors assumption of mutual suspicion. Original-E is the only system I know to do full distributed cyclic GC among mutually suspicious machines < http://www.erights.org/history/original-e/dgc/index.html>. I specify "before I arrived at Electric Communities" because of your requested constraint, and because the secure distributed cyclic GC was already working then. Cap'n Proto is designed primarily for the local C++ bindings. It has the distributed acyclic GC logic I explain, but typically driven by local manual deallocation rather than local GC and finalization. I am not confident of the GC properties of Midori and Orleans. If someone knowledgeable of these systems would comment, that would be great. > > 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. > I didn't say "fine-grained". Erlang requires manual deallocation of processes. Also, you did specify "untrusted". Distributed Erlang does not qualify, exactly because pid are forgeable. > > > 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. What do you mean then by "strong reference"? If Erlang pids are not strong references, then I don't understand what you are saying. > 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. > How do they choose when to kill a process? > > > 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. > That's fair. Driving distributed GC by observing local GC has exactly the problem you point out: As we give one vat more memory, reducing its memory pressure, it observes far fewer finalizations, increasing the memory pressure on its counter-party vats. Perhaps the reason this problem hasn't been too pressing in the past is that none of our vats had enough local memory to cause the problem. > > 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. > What "abundance of widely used alternative designs" do you mean? Of distributed object systems and distributed GC protocols? Sure. I am not proposing to standardize any of these until they've obtained more usage in JS. Of weakref / post-mortem finalization ideas? I think the design space or the remaining controversies here are small compared to many of the other issues that TC39 has been able to converge on. And until we have that, we can't get started on the distributed GC cowpaths we need to move forward on full distributed objects for JS. > > -j > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131111/1115010f/attachment.html>