Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Tips for reducing frame rate spikes due to JIT early in a game?  (Read 20300 times)
0 Members and 1 Guest are viewing this topic.
Offline ashen

Junior Newbie





« Posted 2016-08-12 14:38:55 »

For roughly the first 30-40 seconds in my main 'play game' state there are a series of severe spikes in the execution time of individual frames. These occur very roughly about 5 seconds apart.  Sometimes a spike can cause a frame to be almost 1 second.  At about 30 seconds the spikes start to reduce in severity until the game is running with no noticeable issues.  (PC is dual core, 3.5Ghz, 64Bit, Java 8, 8 GB RAM).

One severe spike can actually be triggered 100% of the time by clicking on a particular button in the game, but only on the very first click.  The spike will not happen again until the game is closed and restarted. I analyzed the code in this button and found nothing that could obviously cause such a big spike. 

This made me think that these spikes are due to methods in my code being compiled by the JIT compiler.  So using the ASM library I wrote a simple test that parses a JAR containing game class files and writes out the number of bytecode instructions for each method. 

The largest method in my main game loop is 2980 instructions while other larger methods are 1891, 1446 and 1037, 1028.  I've read that Hotspot compiles methods up to about 8000 instructions, so I assume these are being compiled ok. 

So I'm wondering if it's worth the effort of say getting all methods down to a max of 500 instructions or so?  I guess that the smaller the methods the faster they can be compiled and therefore a reduction in the severity of spikes?  On the other hand, the event handler for the button that causes a spike is only 45 instructions. 

I've also thought about doing a 'warmup' period where I run the full game loop for say 10 seconds but with input disabled / blank display, just to allow the spikes/compilation to occur without annoying the player.  Right now, I would actually say that a delay of 10 seconds would be less annoying to the player than having to deal with frame spikes while trying to play the game. Is this a reasonable/common thing to do?

Of course, let me know if you think its not the JIT compiler at all.  Thanks.
Offline 65K
« Reply #1 - Posted 2016-08-12 14:55:02 »

Do not bother counting byte code instructions and by no means "optimize" code by reducing method sizes based on guesses what the compiler might do.
Use an ordinary profiler to search for suspicious behaviour, bad performance, memory leaks, etc.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.
Offline ashen

Junior Newbie





« Reply #2 - Posted 2016-08-12 15:02:55 »

@65K

I've been using VisualVM for profiling.  When the spikes occur the garbage collector was at 0%.  The 'sawtooth' heap pattern showed reclaiming of memory only every 20 seconds or so but the GC remained at 0% at all times.
 
I also tried passing Xms and Xmx JVM arguments of 1024 / 2048 to ensure the heap isn't resized.    This worked, VisualVM showed no change to the heap size, but the frame large spikes continued to occur as described above.

I'm not going to try guessing what the compiler might do, but regardless, isn't it a good idea in Java to have many smaller methods both for code maintenance and performance?

Do you think the spikes are caused by the JIT compiler or something else?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 65K
« Reply #3 - Posted 2016-08-12 15:09:16 »

isn't it a good idea in Java to have many smaller methods both for code maintenance and performance?
For performance, no. For maintenance, yes, as long as methods aren't cut into such small pieces that you get the opposite effect: less readability

Do you think the spikes are caused by the JIT compiler or something else?
Nobody can tell without examining your running game.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.
Offline Icecore
« Reply #4 - Posted 2016-08-12 16:24:17 »

warm-up spikes can be fixed with JVM start arguments, (custom build ^^)
Try this:
1  
2  
-server
-XX:+DoEscapeAnalysis

+maybe search more in docs

up: it also may be caused by static fields initialization (new static array list 1000) - in middle of frame
can be fixed by calling all - heavy static data classes - in init phase

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Offline ashen

Junior Newbie





« Reply #5 - Posted 2016-08-13 02:04:56 »

@Icecore, Thanks, I'll try the server and escape analysis flags.  There are so many to read up on, I guess it's very game specific as to what will have noticeable effects or not.

Good point about static variable initialization, I'll have a look at that too.
Offline princec

« JGO Spiffy Duke »


Medals: 950
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2016-08-13 07:54:23 »

Try using two-tier compilation with the server VM.

Escape analysys won't do anything for you.

Cas Smiley

Offline CodeMason
« Reply #7 - Posted 2016-12-26 15:23:23 »

What is two tier compilation for the server VM?  I found this (http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html) but that looks like it is only for the client VM?
Offline Roquen

JGO Kernel


Medals: 514



« Reply #8 - Posted 2016-12-26 17:07:43 »

client/server VM is just a 32-bit VM thing.  Everything's server VM for 64-bit.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1313
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2016-12-26 17:42:14 »

Shouldn't we go back to the original post and wonder whether all assertions are correct?

A 1000ms JIT pause is highly unlikely, given that the JIT does its work incrementally.


I bet it's a code path that the OP isn't expecting, triggering a lot of disk I/O, the incorrect initialisation of a data-structure, etc etc.

If you simply profile your code (and use System.currentTimeMillis / System.nanoTime to confirm your suspicions) you'll most likely find the culprit quite quickly.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 
Ecumene (48 views)
2017-09-30 02:57:34

theagentd (72 views)
2017-09-26 18:23:31

cybrmynd (182 views)
2017-08-02 12:28:51

cybrmynd (180 views)
2017-08-02 12:19:43

cybrmynd (187 views)
2017-08-02 12:18:09

Sralse (193 views)
2017-07-25 17:13:48

Archive (744 views)
2017-04-27 17:45:51

buddyBro (876 views)
2017-04-05 03:38:00

CopyableCougar4 (1423 views)
2017-03-24 15:39:42

theagentd (1316 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!