On Thu, Nov 5, 2015 at 12:30 AM Romuald Quantin <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
