Proxy objects and collection

Daurnimator quae at
Tue Sep 2 13:56:53 PDT 2014

On 2 September 2014 16:40, Brendan Eich <brendan at> wrote:
> Daurnimator wrote:
>>> If the object is freed before the trap, then the trap just gets some
sort of object id.
>> Then it can call out to the external resource manager: "hey, resource id
123 isn't needed any more".
>> Which could then free it.
> That's cool, but what if the id died on the Lua side? You'd have to avoid
recycling it as another object. That makes it very much like a strong

I don't think I understand what you mean here?
Lua will hold onto the object until it is told it can let go.
If (for some reason) the lua vm is destroyed, then the other traps will fail
e.g. the `get()` trap could `throw "VM not available"`

I should note here that this is not unique to lua.vm.js.
I could easily come up with cases where a WebWorker would want to know when
the main thread was done with an object.

>> The discussions around security issues are somewhat interesting,
>> though I think allayed by my proposal of an undefined interval (i.e.
possibly delayed, or random)
>> between the reference being dropped, and the finaliser getting called.
> The trouble comes when one implementation is first or has the most market
power. Then developers (intentionally or not, doesn't matter) come to
depend on its implementation-defined interval.

One of the 'tricks' I had in mind was that we already have this 'undefined'
amount of time behaviour in the browser today;
It just happens to be 'never'!

For the current/old use case of Javascript where the VM is regularly thrown
away, these memory leaks don't matter that much.
But looking to the future, knowing about collection at some undetermined
point in the future would be nice :)

> The next-event-loop-turn thinking I remember from the weak refs threads
may be ok. I don't think there's a fast path for proxies, though. Weak refs
are wanted in ES7 or whatever annual edition after it that they fit in.

That sounds like a okay choice, but wouldn't this mean browsers have to run
a full gc every time they get back to their main loop?
This would seem undesirable.

Is it bad to wait and see what the browser authors do, and then just
standardize on that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list