Garbage Collection

[pprabhu]

I have been working on mods for awhile and a lot of them spawn intermediate temporary objects at high rates. One place that I am doing this is in the PostRender() function, so every rendered frame I create an iterator object to iterate over a set of other objects. This is common practice in environments that have garbage collection, which includes (?) Unreal Script.

The reason the question mark is after "includes" in my previous statement is because I have noticed that Unreal's memory usage under these conditions increases monotonically and linearly with my framerate. I am not surprised that it is rising linearly, but am surprised that it is monotonic. Does anyone know when the garbage collector actually kicks in? Is it only between map switches or are there internal limits to how big the allocated heap space can grow before invoking a GC pass?

It looks like I am going to have to stay away from such frequent allocations, which is a shame (I'd use free if I could) because it means opening access to variables I do not want to make non-private. I know that private is compile-time, but that's beside the point and beyond the scope of this inquiry.

[pprabhu]

I have arrived at a solution, though it is not the optimal one given the circumstances (i.e. there being a patch in development

I would like to raise attention to the fact that Unreal is essentially a massive memory leak between garbage collection times. From my observations Unreal's GC makes no effort to intelligently prune its internal allocation graph (linked list..) at key events. This is unlike other "virtual machines" that intelligently keep tabs on how much has been allocated & (possibly) learn memory usage patterns.

In my server I allocate temp objects very frequently (several times a frame). This was under the assumption that the GC does something between map switches, which it doesn't.

So I made my own memory manager class that lets the user free up & malloc objects from old used objects. Why drop objects entirely when you can recycle them? I use free lists & an internal binary tree to sort out objects that have been freed for future mallocs. i.e. if at some point in time I freed up a "MyClass" and later on I need another one, I could just malloc a "MyClass" to get an instance of MyClass to work with (& initialize) again. This is a very simple model down of what the OS does anyway.

For every invocation of malloc() I have a subsequent free() and voila -- my old memory problem of 1MB/sec is history and I'm at stable memory utilization.

So after all of this my question is is there some way that 227 can perhaps implement this kind of behind the scenes logic? I'd be glad to provide information & code to direct the effort if so.

Here is my UMemoryManager package if anyone is interested in taking a look: UMemoryManager