[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: GC "survey"
- From: "Brownsword, Andrew" <ABrownswor@...>
- Date: Fri, 23 Aug 2002 12:18:46 -0700
I am (still) in the process of evaluating Lua, so I can't answer most of the
questions below. The biggest hesitation in adopting it is caused by the
mark-and-sweep garbage collector. If I understand the current
implementation, it is a monolithic task which happens at times that aren't
directly under user control. It walks across a lot of data, and on some
platforms (i.e. PS2) that is a very painful operation since the machine uses
high latency memory and very small caches. Our normal solution for this
kind of problem is reference counting, which tends to spread the overhead
evenly across execution (I'm not suggesting that this is applicable to Lua,
its just what we usually use).
Another request I have is that all memory allocations be vector-able... and
that the "free" function take the number of bytes being freed. This is very
useful if using a fast lightweight small block allocator. C++ supports this
by the "operator delete (void*, size_t)" overload.
From: Roberto Ierusalimschy [mailto:email@example.com]
Sent: Friday, August 23, 2002 5:36 AM
To: Multiple recipients of list
Subject: GC "survey"
As lhf wrote, we are thinking about a generational collector. The
problem is not how to implement it, but whether it would do any good.
For some applications, a generational collector can be a real booster,
for others it can make no difference from mark & sweep.
To try to improve garbage collection in Lua, we need data about it in
real programs. So, if you think you can have problems with it, please
consider taking some time to tell us about your problems. If you prefer,
send the data directly to us [lua at tecgraf...]; we will keep it
confidential. We cannot promise anything, but such data will certainly
increase the chances.
What we want to know?
* the "size" of your problem (e.g. it should run in Xms but it takes
* the "size" of your data (how many tables? typical size of tables?
how many closures? etc.)
* do you know the time profile of the GC in your program? Where does
it take most time? (mark, sweep, traverse of tables, sweep of strings,
actually freeing memory, etc.)
* does your program respect the "generational hypothesis"? (that is,
most objects die young, before 2-5 GC cycles?)
* does your program have lots of constant data (such as tables that you
set up once, and after that never [or seldom] change again.)? How much?
(This is very important; mainly, those are the data a generational GC
can avoid visiting, and so is the source of its improvements.)
* feel free to tell anything else you think is relevant;
* don't forget to tell which version of Lua you are using, and whether
you modified it in any way that may affect the GC.