Re: GC Compaction

["Peter Hill" <corwin@...>]

John Belmonte:
> I wouldn't say that is true.  Real-time games running on console systems
> with no virtual memory face the same hurdles.  Keep an eye on how game
> developers deal with these issues.

Peter Hill:
> Games in Lua? Or games in C?

John Belmonte:
> I meant Lua, but the issue is present in any language promoting use of
> dynamic objects but lacking compaction, such as C++.

Hmm. In C++ you at least know your objects are a fixed size so you can (if
it is important) create your own free lists of objects. In Lua the Table
type has its size adjusted automatically so you don't have that option.
Otoh, it seems that tables are implemented with only a reasonably small
number of sizes so that, although that fragments memory in the sense of
consuming extra resources, it does reduce long term creep.


Peter Hill:
> Incremental GC is independent of compaction. I very much doubt 5.1 will
> have any compaction.

John Belmonte:
> Sure it's independent of compaction, but it's vital for hard real-time
> systems.

True.

And if one is dealing with real-time systems and also want compaction then
it has a significant effect on the access methods, since one needs to keep a
central pointer list so that compaction may also be done incrementally. Of
course in a *mostly* realtime system one could have incremental gc plus
(very rare) monolithic compaction.

Cheers,
Peter Hill.