Proxy objects and collection
brendan at mozilla.org
Tue Sep 2 18:36:17 PDT 2014
> 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
But when workers are threads in one process (on most browsers today?),
> 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.
More information about the es-discuss