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 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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
