lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, 10 Sep 2001, John Belmonte wrote:

> Thatcher Ulrich wrote:
>
> > I've been gradually working my way through the papers at
> > http://www.cs.utexas.edu/users/oops/papers.html and it seems like,
> > as noted in http://lua-users.org/wiki/LuaInRealTimePrograms,
> > someone just needs to crank out an implementation of Wilson's
> > garbage collector.
>
> Such an incremental garbage collector will allow hard real-time deadlines to
> be met, but will not solve fragmentation issues.  These are separate
> problems.
>
> Lua's memory use can be tuned to alleviate gc time and fragmentation
> somewhat, as Joshua is doing.  However I suspect that such tuning is hard to
> maintain and not always effective.  For fragmentation, in an extreme case
> just one byte allocated at the wrong time could result in megabytes of
> unusable memory.

Sure.  This is the same problem faced by malloc/free.  However, this is
what Johnstone says in his thesis (
http://www.cs.utexas.edu/users/oops/papers.html , paper #10):

	"We showed that for most programs, fragmentation is not a problem,
provided that the memory allocator use reasonable implementations of
well-known policies."

These results are from tracing real programs.  This generally agrees with
the experience of the Munch's Oddysee project I'm working on (game for
Xbox), in which we use the C++ STL extensively and haven't suffered much
as a result of fragmentation (compile times are a different issue :).
Since that's the type of project I'd like to use Lua in, I'm much more
concerned about long GC cycles, since I *know* that will be unacceptable.
If you or anyone else knows fragmentation to be a real problem in a real
Lua program, I'm definitely interested in hearing more about it.

-Thatcher