O(1) mass revocation by deferring to garbage collection?

[ajvincent]

Suppose that we didn't actually clear the proxy's target and handler when calling RevocationController.prototype.revoke().

Instead, we could make proxies's slots subject to garbage collection if their internal reference to the [[RevocationController]] keeps a boolean .revoked property, and that property is true.

We'd modify each of the traps in section 10.5 to check for the revoked property, and to throw a TypeError just as if the proxies were dead (because we'd require that they were), and to actively clear the [[ProxyHandler]] and [[ProxyTarget]] slots at that moment.

The revoke() call simply sets that flag to true, and we're done.

To summarize:

1. Each proxy gets a slot for a RevocationController?.revoked property. Proxies not revocable by a controller have this slot pointing to a constant static false value. Proxies revocable by a controller have this as a reference to a boolean (boolean & revoked in C++ parlance).
2. When the controller's .revoke() method is invoked (which directly owns the boolean), it sets that boolean to true.
3. When executing a trap for a controller-revoked proxy, if the revoked reference is true, then (before calling into the handler but after verifying the handler isn't null): a. Clear the [[ProxyHandler]]and[[ProxyTarget]]` slots. b. Throw the TypeError for that trap.
4. Any proxy with the revoked reference set to true is eligible for garbage collection (or its slots are, if we have to operate that way). Alternatively, if the garbage collector's iterating over objects in memory, it can call a public method to null those references when it does its first walk.

I admit fully I don't understand exactly how garbage collection works in JavaScript engines. But it's cheap to store a boolean, and cheap to store references.

Thoughts?

[ajvincent]

Note: this issue and original comment predate the replacement of RevocationController with a signaling API.