Compiler / GC stalls

Performance Tuning
#1

Hi All

I wrote some code doing a lot of sprite blitting. Works really well - several hundred frames per second using dirty rectangles to avoid complete redraw. Loverly stuff.

The only problem was that I keep getting “jittering” at the start of program execution (performance is stuttery for about first 5-10 seconds). I’ve traced the GC and see that I get a single long GC then many tiny GC events which should be too swift to notice. I presume that the stuttering in performance that I see is JIT - related.

Is there any way around this? It really ruins the start of my game. I’ve started coding this up in C++/SDL for comparison - unless I can find some way to avoid what I presume is compilation stalls, I’m going to just go with coding this up in C++.

#2

There are different ways to handle this ;

  • either you disable JIT compilation with -Xint

  • either you disable background JIT compilation with -Xbatch

  • either you force JIT compilation at startup (before your program start) with -Xcompile flag (I’m not sure of the behavior of this flag)

           Vincent
#3

Which version of the JDK are you using? Are you running the client or server compiler? Which garbage collector are you running? Could you post all of the command line arguments you’re passing to the JVM?

Have you tried specifying -XX:-UseThreadPriorities? Does that have any effect?

#4

Hi Ken, thanks for tackling this…

  • JDK version is 1.5.0_04
  • Running both server and client JVMs (server by preference)
  • I’ve tried standard GC and incgc

This is what I’m using at the mo, but I’ve played with the flags to no avail so far.
-ea -server -Xincgc -Xfuture

I haven’t tried that Thread Priorities flag - I haven’t seen it before. I’ll give it a go.

#5

ok, tried the threads flag - doesn’t make the problem go

#6

Try -XX:CompileThreshold=500

Cas :slight_smile:

#7

I recommend against that, all that’s doing is increasing the number of compiles and probably going to increase the stuttering. You might try -Xbatch to disable background compilation.

#8

What it’ll do is reduce the stuttering to one big pause right at the beginning with any luck.

Something else that kaffiene hasn’t mentioned is what tech. he’s using to do drawing which can have a significant effect on stuttering…

Cas :slight_smile:

#9

And what about precompile at background when showing a start menu? Playstations used this to make things less painful.

#10

Good point - I’m using java 2d (drawimage, fillrect), rendering to a single VolatileImage then drawing that to screen.

#11

Well, that does seem to make it a bit better - at least on my work machine. I’ll need to wait till I get home and try it on my development machine to know if it works well enough on slower hardware, but it does look a bit better already (a twitch or two near the start - in the first 2 seconds or so) then apears to run well after that.

#12

Cas - you’re using a compiler for distributing your java games, aren’t you? Maybe I should look at static compilation for purposes of comparision (just in case some/all of the stuttering is due to my code rather than the JITter kicking in)

#13

Have you tried setting a minimum heap size with -Xms to something realistic?

The best way to do this is to run your app with -Xverbose:gc and see what size
the heap gets to, and then set it as your min. heap size.

Thanks,
Dmitri
Java2D Team

#14

Actually no, I do something mysterious and strange and use a plain old 1.4 client VM for my games (try the Webstart versions, which are virtually identical). I have a feeling your problem is Java2D related, not JIT related, because that’s probably the only difference between your game and my games. Your source images might be in system RAM for a few frames and get punted over to VRAM after a short while or something.

Cas :slight_smile:

#15

No, I’ve left it at the defaults. What’s “something realistic”?

#16

Ahh… that’s possible - I’m not loading my sprites directly to volatile images, I’m just loading them and using them as plain old BufferedImages. I’ll check that out what affect changing that has.

BTW: I tried compiling the java with Jet and it did run very smoothly.

P.S.: Weren’t you arguing against delivering non-compiled Java to people at one stage?

#17

I never argued against it as such… the problem was a legal issue, which I’ve sidestepped by, er, compiling the game. Sort of.

Cas :slight_smile:

#18

Sounds intriguing :slight_smile: Care to elaborate?

At any rate - I switched to loading all the images as volitile images, which seems to have improved things a bit also. I’ll check it out on my development machine later tonight.

#19

Molebox is the solution to your legal woes. It’s a compiler. Of sorts. What JVM? Ahem.

Cas :slight_smile:

#20

This begins to soudn an awful lot like start-up issues.

Are you running on the server VM? You might try the client for grins. Ist not quite as high peformacne but you may not need that little bit of extra eprformance and it stats up much more smoothly.

Otherwise see all the advcie allready given about forcing compile early and “warm up” your system if possible by runnign the render loop for a few seconds without actually rendering.