[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua gc in games
- From: "Jonathan Branam" <sspeare@...>
- Date: Mon, 6 Aug 2001 03:26:08 -0700
----- Original Message -----
From: "Reuben Thomas" <firstname.lastname@example.org>
To: "Multiple recipients of list" <email@example.com>
Sent: Monday, August 06, 2001 2:58 AM
Subject: Re: Lua gc in games
> The idea is more that you only collect the "young" generation most of the
> time (a "minor" collection), and then collect the "old" generation when
> you're really running out of heap (a "major" collection).
I was a little off on what I thought generational meant, thanks for the
clarification. This sounds basically like my const data idea, I guess the
difference would be that I was proposing that the user would give the GC
a hint about where "old" ends and "young" begins.
This does sound like a good solution. I was playing around a little, and
I noticed some interesting behavior. One is that Lua is very rough
about its approximation, and it doesn't do what I think its going to do.
The other is that operations that would seemingly create no new memory,
actually do. At least, Lua updates its "rough approximation of used memory."
Just calling some global functions and looping create memory. It seems like
any parameter passing creates memory, and the temporary and "hidden"
in a loop create memory. In both cases this memory is quickly orphaned.
I am also thinking that perhaps print() is creating orphans, but I could be
> Hopefully, things work out so that in a game you can wait to do a major
> collection until you have the time to walk the entire heap, and the
> generation quickly empties, so that only transient data structures are
This would require some serious looking at. Many games allow up to hours
of continuous gameplay. However, in practice most people at least Save once
in a while, or pause to take a bathroom break. Other games, such as Amped,
could probably make a large estimate of 10-20 minutes before the user stops
In my case, I don't have any expectations of usage, so I'll take as long as
I can get, preferrably forever. ;>
> In other words, you simply don't look at much of the heap a lot of the
> even if it has changed (hopefully it hasn't!). I don't think this is
> particularly hard. It should certainly be easier than incremental
Agreed. This seems much easier than incremental. I think my "const data"
is just a little easier still, but not too much. And it could have more