|
On 7/02/2012 12:44 AM, David Given wrote:
Mike Pall wrote: [...]Reference counting (RC) has plenty of practical problems. One key aspect is that the impact is hard to measure, since the overhead is spread out all over the code. Some issues, like excessive number of writes, cache pollution, unbounded latency vs. delayed free, etc. can be solved with more complex variants of RC.In an earlier life I worked on an object-oriented operating system where all objects were reference counted. Never, never again. Not *only* does it have the problems described above, it's also incredibly brittle and easy to break.
I agree with what Mike says above, but I don't think your argument is relevant David. Just to clarify:
I wasn't suggesting RC as a generic replacement for the current GC.I was suggesting it for certain types of user data (e.g. vector-like objects, strings) where there is no possibility of circular references (so unbounded latency and problems with cycles go away).
The main issue I would like to see solved is that at the moment user data can live indefinitely, until the GC collects it. I would like to see an option so that temporary objects have a lifetime that's bound to scope and usage -- this kind of lifetime is actual apparent from a static analysis of liveness. If you don't want to call it reference counting, call it "static liveness based finalization". RC is just a simple way to implement it based on dynamic liveness.
As far as I can see, the LuaPlus reference counting patch is one solution.Just to avoid confusion: adding vector types to LuaJIT is not going to solve this particular problem in the general case where the User Data originate in C code (e.g. matrix types, unicode strings, any other user data you want to use with infix operators).
As to "brittle and easy to break" I think this depends on your implementation. With language-level support (e.g. Python uses RC as far as I know, C++ smart pointers, or static analysis) it isn't easy to break -- at least in these non-circular-reference cases.
Best wishes, Ross.