[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Some questions and proposals about GC and memory management in Lua
- From: Thomas Jericke <tjericke@...>
- Date: Thu, 25 Jul 2013 09:27:07 +0000
On 07/24/2013 05:08 PM, Leo Romanoff wrote:
I think you need to look into the possibilities again. You can stop the
GC, resume it or run it with steps.
here is a second part of my questions and proposals reagrding using Lua as a target language. This time I'd like to cover some topics related to garbage collection and memory management.
Lua provides GC and memory management mechanisms. In general and especially when used as a target runtime platform it is important that runtime supports these mechanims in an efficient and flexible way.
As far as I know, Lua currently provides very little if any possibility to control these two mechanisms (well, you can tweak some GC params a bit). IMHO, a richer set of APIs may be useful to make it more flexible and more efficient.
- Often, when Lua is integrated with/into C/C++ code, you need to have a more explicit memory management and control over lifetime of objects shared between Lua and C/C++.
- In many cases (e.g. gaming) people also want to have a more strict control over garbage collections in terms of being able to control GC pauses and a time when they are allowed to happen.
- Many people reported that they'd like to have the ability to collect certain objects "right now". This is why many propose reference-counted GC as a way to achieve it.
- In case of e.g. using multiple Lua states, it could be useful to use different memory management approaches due to different requirements and different lifetimes. Thereore it would be nice to have a customizable way to define memory management hooks on a per Lua state basis (or even at a lower granularity)
- Yet another issue, where I'm not sure about what's possible already today, is the ability to refer to Lua objects from userdata objects. Is it possible today? I.e. can I create a userdata C-array which refers to Lua objects directly? IMHO, it is not the case today, because it would introduce problems with current GC implementations as they are not able to trace inside userdata objects. But I think that being able to refer to Lua objects from userdata could be very useful for an efficient implementation of many data structures.
Based on these arguments, I'd like to discuss the following proposals:
1) Ability to define memory management functions per Lua-state (or even per object type, per metatable)
For example, one could set custom malloc/calloc/free callbacks. By default, they would refer to what is used today. But one could provide custom implementaions, e.g. based on memory areans or region-based approach. BTW, if I remember correctly, LuaPlus allows something like this already. And the required changes are minimal. It is just about adding a few pointers to the LuaState structure.
This is already possible. See lua_Alloc
If think it would be hard to do this. You would need to have a full API
between the custom GC and the Lua interpreter to make this available.
2) Ability to set/plug-in different garbage collector per Lua state (or even per metatable type, i.e. per object type)
For example, if some states/objects should be collected as soon as possible, one could specifiy a reference-counting GC to be used for them. And for other states/objects, one could set the default mark&sweep garbage collector.
3) Ability to provide custom garbage collector implementations.
It would be nice if Lua would define an API/interface for garbage collectors, so that one could "easily" plugin its custom implementation as long as it satisfies that interface. There should be also functions to set/get a current garbage collector e.g. for the whole program, current state, specific Lua state or even per object type (see previous bullet)
Currently you can use the lua_gc function to control the GC. This is per
luaL_ref and luaL_unref give you a nice way to handle references from C
4) Ability to provide a custom tracing method for garbage collector for a user-defined type (may be via __trace method in a metatable).
This way user-defined types may refer to Lua objects, which may allow for implementations of more efficient data structures in C/C++, which refer to Lua objects. And by means of a tracing method, the GC is still able to do its job and trace all objects.
Just an idea: Eventually, existing built-in methods for tracing Lua tables could be even registered in the same way. After all, tables are a very special kind of a userdata ;-)
5) Ability to provide custom finalizer and custom tracing function to be invoked when object is being garbage collected (so that it can mark referenced objects as non-references and release resources).
This is probably done already done by the existing __gc method. If not, its semantics could be extended or a new method could be introduced.
The __gc does that, what would you need beyond the current functionality?
I think most of what you want is possible, with exception of defining
custom garbage collectors.
OK. That's it for now.
Please feel free to grill these proposals :-) Any comments are welcome!
I'd also like to hear about other alternatives to control memory management and GC in Lua.