On Thu, Apr 7, 2011 at 9:15 PM, Mark S. Miller <erig...@google.com> wrote:
> > > 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, >> > It's worse than a high bandwidth covert channel, it's a high bandwidth side channel: < https://mail.mozilla.org/pipermail/es-discuss/2010-September/011717.html>. > 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
