Daurnimator wrote:
On 2 September 2014 16:40, Brendan Eich <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
