Bounded GC

There was talk some time ago about implementing something along the lines of:

System.gc( int n );

which would tell (ask) the garbage collector to run for at most n milliseconds. This would replace or be used in combination with the Thread.sleep( int n ) call that might appear in gaming loops.

Alternatively there could be a way to ask the GC to run while a buffer strategy is waiting for the video sync to flip buffers. Thus allowing the GC to optimally use the ‘dead’ time in a typical game or animation loop.

Has anymore thought gone into that? Now that we have Ken here, who I read previously worked on the HotSpot team, perhaps he could comment on the feasibility or nudge the appropriate people to make this part of Java 1.5?

I think Jeff indicated that the first case of limiting the GC to N ms was quite doable according to the guys he talked to.

I see a problem with this. Right now there’s the rule “no allocating in the main loop”. Adding bounded GC would give us the rule “you can allocate some, but not enough to overwhelm what the GC can collect in about 10ms”. And of course, this rule would change depending on the deployment scenario. I imagine it might be pretty hard to determine just how many new’s you’re allowed and of what size each new should be.

It seems to me that this would make programming harder than just using the no-allocation rule. Unless, of course, the GC can collect gobs more in a few ms than you would ever likely allocate.

The “no allocation” rule is more of a guideline. As I recall Cas mentioned that Alien Flux does some small allocations in the main loop. Combined with other options to minimize GC delays (e.g. concurrent GC) and adjusting the heap size appropriately you should be able to allocate in the main loop if you are careful not to get carried away.

I think not allocating anything in the main loop is a very large restriction. That alone might undo much of the productivity gains that Java otherwise would give you, as it can effect the design significantly.

And remember that if the GC is invoked for a few ms EVERY FRAME that it adds up to a significant amount. Also, I don’t see that this would do any harm… if there will be GC interrupting the main loop it is best to have something like this to help minimize the disruption.

Turn on verbose GC (I use -Xloggc:) in your game to see how frequently GC takes place and how long it runs… that will give some better idea of how effective this might be. I would like to hear the results from anyone that would like to try that experiment actually.

The problem is very simply, to avoid allocating so much that the processing time required to collect the garbage exceeds what time you’ve got left over from drawing. I can safely allocate aliens and particle emitters in my rendering loop without any trouble at all, and numerous other sundries.

I perform a full GC at opportune moments (level end), and with Jet, I already have a bounded collector.

Rather than specify the bounds using System.gc(int) it might be prudent to supply the value as a -X switch. It is, after all, only a suggestion to the garbage collector about how long it needs; if it needs more time, it’ll have to use more time. In other words, I think it’s a platform tuning question rather than a programmatic one. At this stage.

Cas :slight_smile:

[quote]Rather than specify the bounds using System.gc(int) it might be prudent to supply the value as a -X switch. It is, after all, only a suggestion to the garbage collector about how long it needs; if it needs more time, it’ll have to use more time.
[/quote]
The way I was thinking the only time it would really take (significantly) more time was when it was triggered by an allocation that would otherwise fail. Even in that case it would not trigger a full GC, but only enough to satisfy the allocation… a true full GC would only ever happen when System.gc() is called (with no bounds).

But I don’t know enough about it, so maybe you just can’t work it that way.

We all know the GC was never tailored for Games.

Spose the key question is; should Sun (now they have a fairly official games division) now retailor the GC so it supports the needs of Games.

I say Yeah!
We all prolly say Yeah!
All it takes is for 1 high up n00by(aka Manager :p) @Sun to say Nay, and we’re all scuppered :frowning: