Le 03/11/2013 11:29, Bobby Holley a écrit :
The problem with weak references is that they put the GC in the driver's
seat, which makes it very hard to avoid revealing GC secrets to the client.
Instead, I propose that we let the client code drive, and see how far we
get with hueyfix-style tools.
hueyfix-style tools for client code or implementors?
Client code will have one in ES6 in the form of revocable proxies.
Initial post on the topic (mentioning GC specifically) [1] and API [2]
(also available in the latest ES6 draft).
In a nutshell:
let { proxy, revoke } = Proxy.revocable(target, handler);
proxy.foo // traps
revoke() // always returns undefined
proxy.foo // throws TypeError: "proxy is revoked"
One of the major difficulties with leak prevention on the Web is that there
are often two phases of retirement for a given object. The first happens
when the object goes away semantically - when a window is closed, when a
node is removed from the DOM, when a connection is terminated, etc. The
second happens when the object is actually GC-able, which depends on the
graph of references in the VM, and can occur at an arbitrarily distant
time. The interval from the first to the second is general the period in
which JS "leaks".
What if we give script the ability to say "this Foo is semantically dead -
please neuter cross-global references to it"? This is effectively what we
have with Cu.nukeSandbox, and it works well. It doesn't in any way expose
GC behavior, but it lets callers give the GC a much-needed boost, which the
GC may subsequently leverage if it turns out to be useful.
I don't understand the "cross-global" part. I don't think that's the
main cause of leaks in problem usually.
But revocable proxies allow this sort of expressiveness (at arbitrary
granularity, not just cross-global).
This won't solve esoteric cross-vat use cases, but I think it would be a
nice way to bulldoze the subtle gotchas that make it so easy to introduce
subtle leaks in large-scale JS.
I agree, but can't help adding: "...at the cost of try/catch all over
the place".
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-August/024344.html
[2] http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
