Does anyone have a link, or some information on some best practices for game programming in Java to minimize the occurance of the garbage collector? Or even better, is there a debugger/monitor out there that'll watch and display garbage collector information for a program?
I've tried to optimize my application as best as I can, but am noticing that once in a while, the gc fires off and I get a stutter in my framerate.
Any help is appreciated!!!
The only thing I know of is to be careful about how many objects/arrays you are creating each frame. Or I should say how many are collectable each frame.
Try to get it so you don't create any native buffers each frame (use the same ones over and over). You probably already do that.
Also, I've noticed that using the new 5.0 foreach version of the for loop (i.e. for(Object obj : m_objects) ) seems to create objects for some reason. Its probably a result of creating an iterator.
Netbeans has a profiler (separate download) that will watch garbage collector information (I think :D )
EDIT: You also might try searching SourceForge for a Java profiler.
In eclipse you have the "TPTP : Eclipse Test and Performance Tools (http://www.eclipse.org/tptp/)" plugin to profile your code, if I remember it shows you memory usage...
Quote from: "Fool Running"Also, I've noticed that using the new 5.0 foreach version of the for loop (i.e. for(Object obj : m_objects) ) seems to create objects for some reason. Its probably a result of creating an iterator.
Ja, it's the iterator due to the contract of the general collection framework. It's a deep GC pitfall, especially if you're using nested 5.0-foreach statements in your main game loop. We decided to replace nearly all collection work by Javolutions FastCollection: http://javolution.org/api/javolution/util/package-summary.html#package_description ... slower when populating, but fast and no garbage when iterating.
A good starting point is: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html which links to VisualGC/jvmstat here: http://java.sun.com/performance/jvmstat/ ... not too difficult to setup.
Cheers,
Sor
Wow... that javolution stuff is great! I especially like that you can simultaneously access FastLists without synchronizing.
I've gone through, implemented javolution, used jconsole, watched memory usage, have probably "over-optimized" my memory usage (if there is such a thing)... but am still getting the occasional stutter in my app. I'm beginning to wonder if it's not gc after all. I've placed timers all throughout my game to try and pinpoint the exact cause, but it's coming back as random pieces that don't make any sense (which made me think it was the gc, since it seemed to be something happening independent of the game). Could it be a background process happening on the machines? It does seem to respond differently on different computers.
Is there a way to make an LWJGL game to not be so reactive to background processes that are running?
Thread.setPriority
I get nervous changing thread priorities. What's the common practice? Also, I generally have two (preferably 3, but limited to 2 now) threads running for the game (a server thread, a client thread, and sometimes a background music thread - although that's now integrated into the client thread to reduce any thread fighting). Should I bump both threads up a priority notch you think?
How bad of a stutter is it? Is it actually noticable without a FPS counter?
If your FPS is high (like greater than 100) and it drops occasionally to like 85 (i.e. not that great of a drop), then it might just be the OS eating up some cycles for something.
If its not noticable to the user, then I would say just leave it :D
Yeah, it's not "terribly" noticeable, and only happens at random moments. The framerate is generally around 150, and drops about 15 to 20 and then jumps back up. It just creates a little "stutter" effect to an otherwise smooth gaming experience. I've played around with a bunch of other lwjgl games (good work everyone! :) ) and they seem to experience similar stutters once in a while. It seems minimal if people keep vsync enabled though.
Ho hum.... feel free to try the game at: //www.tommytwisters.com/spaceops/spaceops.jnlp and offer any feedback as to what you think it may be.
I assume you are using Windows...
Try killing Explorer and see if your game runs smoother :D
I did notice slight stutters and they seemed to go away when I killed Explorer...
Its possible I'm just crazy, though :lol:
EDIT: Nevermind... I tried it again and it was still smooth with Explorer running. I did have to let it settle down a little though.
Is it possible that the stuttering stops after a while (after the GC finishes collecting stuff, or something)? Have you possibly tried a System.GC() right before the main game starts (after you've loaded everything)?
Nice game BTW 8)
Do you use OpenAL with a streaming sound source for the background music, to which you queue just in time decoded data chunks?
I've actually tried it on a Mac and Windows both. I've also placed System.gc() after the load sequence.
I do use openAL with a streaming sound source for the background music. I used to run it in its own thread, but have since placed it's update routine into the main gameloop to prevent thread competition.
For an update: I tried turning off the music completely. It didn't make a difference. :(
I also noticed that it does seem to clear up after time, but that first 30 seconds is pretty rough.
All textures aligned to 2^x boundaries?
Trick question.
Whenever I load up a texture, if it's not power of 2, then I add "dummy space" to make it a power of 2. I use mipmapping for texture scaling. And then the textures can be placed on any size of poly or object.
I just uploaded a new version of the demo... so please feel free to try it again and let me know if the stuttering is still there. I tried reducing yet more of my resource usage.
I don't know about stuttering or anything since I haven't played it that much...however the game looks really cool. Kinda like a souped up asteroids (which is a good thing). It also reminds of this old Star Trek game I played many years ago. I don't quite remember the name of it though.
Well, the point is...really cool work.
before suspecting GC, you could run with -verbose:gc. Maybe the problem isn't gc at all.
umm had a similar problem with my apps, wasnt the gc though, it was the threads, I lowed the priority of less important threads(as i was networking so i had a few)like listening thread as it was tcp, and only slept the main game server thread interval minus clocktime, then sent an update 2 the other threads 2 do there thang. and sleeped them for only (1) if they hadnt been updated, done wonders for performance dont know if its a good thing 2 do