Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow limiting the memory usage of individual Lua states #9

Open
GoogleCodeExporter opened this issue Mar 12, 2015 · 5 comments
Open

Comments

@GoogleCodeExporter
Copy link

I had the requirement to limit Lua VMs to a maximum memory usage for better 
sandboxing. This is actually pretty easy thanks to Lua offering a way to supply 
a custom allocator. I extended JNLua a bit to offer seamless support for this:
- Added a new constructor that takes the initially allowed maximum memory. If 
this constructor is used instead of the default one, the custom allocator will 
be used. If not, the default allocator will be used, so there's no impact on 
performance in that case.
- Added getter and setter for allowed maximum memory: 
getTotalMemory/setTotalMemory. This value can be changed at any time for an 
existing Lua VM that was created with the new constructor. Due to the allocator 
being decided upon VM creation this cannot be enabled afterwards.
- Added a getter for current memory consumption: getFreeMemory. This is the 
exact remaining number of bytes the allocator may still use.

Keep in mind that the native library compiled with this patch will only work 
with the patched LuaState class, since the native library accesses the new 
fields in the LuaState class: using an older implementation will crash (field 
not found). I quickly scrolled through jni.h but didn't see anything that 
allows checking for the existence of a field without throwing an error.

The attached patch is for release 0.9.6. I'm sure it will be very simple to 
port this to the 1.x branch, but I just don't need it so I won't.

I'm providing this patch no strings attached, use it as you see fit. Ideally 
I'd hope for this to get integrated into the repository, so I don't have to 
patch it whenever there's a new version - I tried to match the existing code 
style as closely as possible.

Final disclaimer: I only tested this on Windows, but I don't see why it 
wouldn't work on other systems (there's no platform specific code in the patch).

Original issue reported on code.google.com by fnuecke on 19 Aug 2013 at 9:15

Attachments:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant