 |
lua-l archive |
|
|
||
|
On 2017-07-27 01:45 AM, Daurnimator wrote:
On 27 July 2017 at 14:39, Soni L. <fakedme@gmail.com> wrote:What stops Lua/Fengari from having its own GC? Just make it so pushing a JS object/lightuserdata finds or creates a lookup table entry for mapping between JS and the GC? And don't expose Lua GC objects? This gives you the exact Lua/C behaviour without screwing up the JS GC. (Heavy userdata may be trickier, tho. Maybe require use of typed arrays or something?) I don't see why you'd need synced GCs. (I do see why one would want them, because it simplifies implementation. But it's not portable - e.g. for weak tables. Even if you could do a synced GC with JS, would you still be able to do Lua 5.2+ ephemeral tables?)Because you need to be able to do a full sweep, otherwise cycles cannot be detected. JS (and the DOM) expose no way to do a full sweep: so we can't write our own GC and still be able to call arbitrary JS functions. The only solution was to structure our code so that the JS GC also behaved as the lua GC.
If you control every object inside your state you can do a full sweep.As I said, treat pushing arbitrary JS objects as equivalent to pushing arbitrary lightuserdata. GCing those objects does no cleanup, leaving the cleanup to JS. But tables can still get __gc, since you have your own GC, with your own JS-based data structures.
If heavy userdata were just blobs of bytes, you'd also be able to add __gc to those. And cleanup would be all about using a JS array and inserting objects into it and removing objects from it when __gc is called, and so on. You'd be able to call __gc, you'd be able to do everything normally. It'd be a fully featured Lua.
To call arbitrary JS functions you do an FFI that manages those heavyuserdata for you. JS objects get put in an array, __gc removes them from the array, __index looks them up in the array, etc. If it's possible to FFI C++, then it must also be possible to FFI JS.
-- Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.