On Thu, Apr 7, 2011 at 9:11 PM, Mark S. Miller <erig...@google.com> wrote:
> Hi Mikeal, > > I do not yet understand your server example. Perhaps a bit of illustrative > code would help? > > In any case, within memory-safe gc languages, there are several well > motivated enhancements of the API of the collector. Several of these are > fundamental, in that there is no way to emulate them in their absence. > Ephemeron tables aka WeakMaps is one. Weak references < > http://wiki.ecmascript.org/doku.php?id=strawman:weak_references> is > another. Given just a normal GC, neither can be emulated. Either one by > itself is inadequate to emulate the other. WeakMaps are weak references were > written as separate strawmen because, once separated, they are cleanly > different > Oops. "WeakMaps *and* weak references were ..." > abstractions. > > * WeakMaps by themselves do not make GC observable. They simply provide a > collection abstraction designed to make each value accessible based on the > *conjunction* of access to a WeakMap and to a key. Because access requires > this conjunction of prior access, strong reachability of the value should > likewise be based on strong reachability of both the WeakMap and the key. No > other existing or proposed construct (including weak references) enables one > to arrange such conjunctive reachability relationships. Were WeakMaps > enumerable, then access to the WeakMap by itself would be an adequate > condition to access its keys and therefore its values. > > * Weak references, especially when coupled with post mortem notification, > is all about observing and reacting to collection decisions. By fetching a > strong reference from a weak reference, the "mutator" (i.e., the program > rather than the collector) can cause a non-monotonic transition of a value > from non-strongly-reachable to strongly-reachable, provided it performs this > fetch before the collector notices this non-reachability and collects that > value. To do a distributed object system such as < > http://erights.org/elib/distrib/captp/> < > http://code.google.com/p/caja-captp/>, we desperately need weak references > and post mortem notification, in order to compose local collection into > distributed acyclic collection. Because the ability to create weak > references enables one to observe collection, and therefore enables one to > read a high bandwidth covert channel, the ability to create weak references > is a capability must not be given out lightly, and should be encapsulated by > such distributed object systems (as it was in E). By contrast, the ability > to create a WeakMap can be made generally available. > > * Local GC + WeakMaps + weak references with post mortem finalization are > still not adequate to compose local collections into full distributed > collection, including the collection of distributed cycles. < > http://erights.org/history/original-e/dgc/> explains a full distributed GC > system designed by Arturo Bejar and implemented within (the language now > known as) Original-E. It relied on adding a new API to the JVM collector > (back in Java 1.0.x days IIRC), to obtain reachability-change information > that cannot otherwise be derived from the local collector. Were the > standardization process infinitely malleable I would write up a strawman for > this as well, but my sense is that this would be a bridge too far for a > standards process. > > Could your server example be handled by weak references with post mortem > notification? Though I don't yet understand it, that would be my guess. I do > intend to propose weak references for the next round of ES standardization > after ES-next. > > > On Thu, Apr 7, 2011 at 7:13 PM, Mikeal Rogers <mikeal.rog...@gmail.com>wrote: > >> requests come in to a server, you want to stick them in a hash so that you >> can query the server at any time for all the "current" queries. >> >> the problem is that, when using objects, you'll always leak. there are too >> many reasons a request might "go away" and too many asynchronous "owners" of >> that request to reliably remove it from the hash, especially in node. >> >> ephemeron tables looked like a good way to solve this, we can stick them >> in the table and when nobody else has a reference to them they get >> collected. at any point we can query the server for all existing >> request/response objects. >> >> if we have no way to enumerate the map we can't do this. >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
