Question about Weak Maps
Why would you want to enumerate the keys in a weak map?
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20110407/57055ffd/attachment
long post a while back about the security problems w/ enumeration on weak maps if you search for it.
[Disclaimer: I'm not an expert at server code. That said...]
Don't you generally need to manage the policy for these kinds of requests manually anyway? In particular, you can't actually tell if a user has abandoned their session, since the browser doesn't let you know when that's happened. So it's up to your server to decide what policies to use for expiring requests.
With strong maps, you can do all this stuff explicitly, but it's not dependent on the GC:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets
With weak maps (which BTW are just a renaming of ephemeron tables), you depend on the GC for memory management, but you don't get enumeration. This was always the case with the design, even before the renaming.
MarkM designed them this way in order to avoid security issues (he can probably explain these issues better than I), but there are portability issues as well: if you expose the current set of bindings in the table to programs, then they will be able to depend on the non-deterministic behavior of the GC. Experience shows that when specs introduce unspecified behavior, the web begins to depend on implementation-specific details.
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 < 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 < erights.org/elib/distrib/captp> <
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. < 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 9:11 PM, Mark S. Miller <erights at 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 < 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 ..."
On Thu, Apr 7, 2011 at 9:15 PM, Mark S. Miller <erights at google.com> wrote:
On Thu, Apr 7, 2011 at 9:11 PM, Mark S. Miller <erights at 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 < 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 < erights.org/elib/distrib/captp> < 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: < esdiscuss/2010-September/011717>.
Weak Maps seems to have superseded ephemeron tables.
They are non-enumerable, does this also exclude any call that gives you an array of the current keys?
If this is the case then it excludes the primary use case we have in node for ephemeron tables.
I can understand why you might want to limit enumerability because a gc could mutate the map during enumeration but I desperately hope there is still a way to get the current list of keys and inspect the values provided that you guard against the key going away.