Proxy objects and collection

Brendan Eich brendan at mozilla.org
Tue Sep 2 18:36:17 PDT 2014


Daurnimator wrote:
> On 2 September 2014 16:40, Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> 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 reference.
>
> I don't think I understand what you mean here?
> Lua will hold onto the object until it is told it can let go.

Oh, if you hang onto the object on the Lua side just because there's a 
reflecting Proxy for JS, even though there may be zero JS refs, then 
you'll indeed keep the id alive and not have replay bugs.

But in this case I believe you will have memory leaks, due to Lua 
waiting for JS GC when it could know the object lost all JS refs and 
*then* died from loss of Lua refs.

We've had these in Mozilla code using C++ and JS heaps to refer to C++ 
objects and their JS wrappers. We fixed them by being sufficient eager 
no matter which side's refs die first.

> 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.

Yes, and if the worker is process-isolated there is a distributed GC 
problem.

But when workers are threads in one process (on most browsers today?), 
it's easier.

> 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.

I think not -- GCs are not only generational but incremental -- or 
heading that way. So they should be able to collect often, in increments.

> Is it bad to wait and see what the browser authors do, and then just 
> standardize on that?

No, see the bad game theory I outlined. Winner takes all and spec 
follows that, which overspecifies GC.

/be


More information about the es-discuss mailing list