Rembulan, a new Lua 5.3 implementation for the JVM built with sandboxing in mind

[sandius 0]

Hello everyone,
 
I'm not entirely sure what Lua implementation is used by OpenComputers (I'm assuming you use a patched version of LuaJ). In any case, I would like to invite you to take a look at Rembulan, a new implementation of Lua 5.3 for the JVM, built with sandboxing in mind. (I'm the project's author.)

 
The project lives on GitHub here:

• https://github.com/mjanicek/rembulan

Here are the first two paragraphs from the project's Readme, for your convenience:
 

Rembulan is an implementation of Lua 5.3 for the Java Virtual Machine (JVM), written in pure Java with minimal dependencies. The goal of the Rembulan project is to develop a correct, complete and scalable Lua implementation for running sandboxed Lua programs on the JVM.
 
Rembulan implements Lua 5.3 as specified by the Lua Reference Manual, explicitly attempting to mimic the behaviour of PUC-Lua whenever possible. This includes language-level features (such as metamethods and coroutines) and the standard library.

As I mentioned above, I assume you're using a patched version of LuaJ. So, what does Rembulan offer that LuaJ doesn't? There are four main points relevant to OpenComputers:

1. Rembulan implements what I call "CPU accounting": Lua programs may be allocated a number of "ticks" for which they are allowed to run before they are paused (and resumed later). These pauses are transparent to the Lua programs. In other words, Rembulan allows you control over the CPU time spent by the user programs. (I'm not aware of an equivalent functionality in LuaJ.)
2. Coroutines in Rembulan do not use Java threads (as opposed to LuaJ). They are therefore much lightweight and coroutine switches them do not involve a thread context switch. They work with CPU accounting (above). This should allow you to have an order of magnitude more coroutines than with LuaJ.
3. Rembulan implements Lua 5.3, whereas (IIRC) LuaJ implements Lua 5.2.
4. It's possible to have per-state metatables (e.g., for booleans or numbers) in Rembulan, whereas in LuaJ these are accessed via static fields, i.e., by default shared by all programs run on the JVM.

Points #1 and #2 are especially good-to-have (I think). I don't know to what extent you might have addressed similar points in OpenComputers, though: I have seen mentions of Lua 5.3 in the documentation (#3); I would not be surprised if you also addressed #4. However, I find #1 and #2 to be not doable in LuaJ, while at the same time being crucial for sandboxing and scalability, respectively.

There are of course downsides and caveats:

• The project is not yet as mature as LuaJ, and a significant part of the standard library is still missing (most notably the module library). However, the runtime is by now mostly stable, and I do not expect it to change much until the release. (A detailed overview of the state of the standard library may be found in the documentation.)
• Given the fundamentally different implementation strategy, libraries written for Lua in LuaJ will not (at this point) work in Rembulan. It should, however, be possible to implement a LuaJ-to-Rembulan adapter that might do at least part of the job.

That said, it might be worth trying Rembulan out to see whether it could be used in OpenComputers at some point in the future, and perhaps help shaping it?

I'll be happy to answer any questions!

[PixelPi 0]

Of the little that I have understood the main motivation for Eris was persistence:

 

https://github.com/fnuecke/eris

 

From my personal view this is one of the coolest features of OpenComputers.

[tim4242 1]

OpenComputers only uses LuaJ when nothing else is possible, otherwise they use a native implementation for speed plus eris for persistance.

[sandius 0]

[Aargh, sorry for the late reply, I thought I would receive an email notification to draw my attention back here...!]

 

Thanks a lot your replies! I contacted the devs on GitHub and it indeed appears that OpenComputers is using LuaJ as a fallback. Besides persistence (which I have on my list), the native Lua used in OpenComputers also seems to allow memory limiting, and that is very much on the frontier of what I plan to support in Rembulan, at least with the current design.