Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Brendan Eich]

On Thu, Nov 5, 2015 at 12:30 AM Romuald Quantin <romu at soundstep.com> wrote:

> What is the problem in accessing the keys with any code, which is the same
> behaviour for any other object in javascript: String, Array, Object and so
> on. The point is being able to do on a weak key so code can be processed
> without being retained by the GC.
>
>
That's one point, but not the only one. Think of a WeakMap wm as the dual
of a private field pf, named by a symbol:

obj[pf] // get the value of a symbol-named field
wm[obj] // get the value of a weak-mapped field

A second point of not enumerating weakmap keys is to enable engines to
transpose from the wm[obj] to the obj[pf] form, unobservably. I believe the
Chakra engine in IE and Edge does this. It's a performance win, as usually
the key (obj) outlives -- or lives only as long as -- the map (wm), so
hanging the map as a pf off the obj's hidden class causes no memory leak
due to an unwanted strong reference.

The untransposed case requires the JS engine's garbage collector to treat
weakmaps specially, with bad worst-case complexity (think of tying knots
among keys and values in a weakmap or set of maps -- a global mark/sweep
phase would be required). More on weakmap GC overhead:
https://esdiscuss.org/topic/linear-time-weak-map-gc (clever improvement
there, but still hairy compared to the transposed case, which is just
objects with hidden classes, etc., in all engines today, plus private field
keys that can't be enumerated).

A third point is the one Rick cited: in an Object Capability security
model, giving a capability to wm should not give you all the keys. This is
the POLA in action. Yes, someone debugging a system built with weakmaps
would want the keys. In a stratified host/guest scenario, the host wants to
debug the guest's code and heap, including finding all the keys. But for
the guest there should be no capability leakage.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151105/daa71c45/attachment.html>