5 ms·

Lua has goto (and JS does not), which means not all cfg's are well structured. That could impact the compiler in certain ways. Lua also has finalizers, which e

by yoklov 11y ago

Lua has goto (and JS does not), which means not all cfg's are well structured. That could impact the compiler in certain ways. Lua also has finalizers, which effect the GC's design. The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way (but to my knowledge LuaJIT doesn't support 5.3 so...) There are other issues too, but these are just off the top of my head.

striking 11y ago
LuaJIT supports the 5.1 Lua standard, so goto doesn't exist. Yeah, finalizers and weak key value stores would be an issue in certain versions of JS.
- pygy_ 11y ago
  LuaJIT supports goto out of the box, as well as many other Lua 5.2 features, some behind à compiler flag.
  - striking 11y ago
    I stand corrected. Thanks!
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
mraleph 11y ago
> Lua also has finalizers, which effect the GC's design. V8 has a weak callback mechanism, which (while not exposed to JS) allows reentering JS from inside a weak callback - which means you can emulate Lua's __gc on top of this mechanism. > The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. If we disregard lua_topointer then Lua/C API only leaks internal pointers for strings (lua_tostring), userdata (lua_newuserdata, lua_touserdata) and threads (lua_newthread,lua_tothread) - everything else is manipulated using lua_State's stack. This means VM only has to take care with regards to these objects. Userdata and threads can be just allocated outside of movable part of the heap and strings can be "externalized" (i.e. they payload relocated into the immovable space) on first access via lua_tostring. Coincidentally last thing is something that V8 supports[1] (though of course externalization is not a cheap operation as it requires copying). > Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way Yeah, that's certainly a whole ton of work, but most of this work would be pretty technical. JS engines might actually get int64/uint64 value types in the future (at some point there was an ES7 proposal - but currently it does not seem to be on track for inclusion). [1] https://github.com/v8/v8-git-mirror/blob/master/include/v8.h#L2344-L2353 https://github.com/v8/v8-git-mirror/blob/master/include/v8.h...
- piotrjurkiewicz 11y ago
  LuaJIT does not support 64 bit integers. It uses double NaN tagging for storing object references. That's the basic principle of LuaJIT design and one of the most important source of its superior performance. In this matter, it is very similar to JS VMs. Support for 64 bit integers would require to abandon this model and completely redesign the LuaJIT VM. Mike opinion about that was very negative. I believe that this was one of the reasons he decided to abandon the project: he was disappointed by Lua creators decision to introduce 64 bit ints and the fact that LuaJIT can't be made Lua 5.3 compatible without rebuilding it from scratch (but that's only my personal impression).

by yoklov 11y ago

striking 11y ago

LuaJIT supports the 5.1 Lua standard, so goto doesn't exist. Yeah, finalizers and weak key value stores would be an issue in certain versions of JS.

pygy_ 11y ago
LuaJIT supports goto out of the box, as well as many other Lua 5.2 features, some behind à compiler flag.
- striking 11y ago
  I stand corrected. Thanks!

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

mraleph 11y ago

> Lua also has finalizers, which effect the GC's design. V8 has a weak callback mechanism, which (while not exposed to JS) allows reentering JS from inside a weak callback - which means you can emulate Lua's __gc on top of this mechanism. > The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. If we disregard lua_topointer then Lua/C API only leaks internal pointers for strings (lua_tostring), userdata (lua_newuserdata, lua_touserdata) and threads (lua_newthread,lua_tothread) - everything else is manipulated using lua_State's stack. This means VM only has to take care with regards to these objects. Userdata and threads can be just allocated outside of movable part of the heap and strings can be "externalized" (i.e. they payload relocated into the immovable space) on first access via lua_tostring. Coincidentally last thing is something that V8 supports[1] (though of course externalization is not a cheap operation as it requires copying). > Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way Yeah, that's certainly a whole ton of work, but most of this work would be pretty technical. JS engines might actually get int64/uint64 value types in the future (at some point there was an ES7 proposal - but currently it does not seem to be on track for inclusion). [1] https://github.com/v8/v8-git-mirror/blob/master/include/v8.h#L2344-L2353 https://github.com/v8/v8-git-mirror/blob/master/include/v8.h...

piotrjurkiewicz 11y ago
LuaJIT does not support 64 bit integers. It uses double NaN tagging for storing object references. That's the basic principle of LuaJIT design and one of the most important source of its superior performance. In this matter, it is very similar to JS VMs. Support for 64 bit integers would require to abandon this model and completely redesign the LuaJIT VM. Mike opinion about that was very negative. I believe that this was one of the reasons he decided to abandon the project: he was disappointed by Lua creators decision to introduce 64 bit ints and the fact that LuaJIT can't be made Lua 5.3 compatible without rebuilding it from scratch (but that's only my personal impression).