[java] JVM 'warm-up' time Q
Ok, I have embarked on the Grand Experiment and, equipped with the latest JDK, Java3D, JMF, and Eclipse I set forth to conquer the world.. well, kinda.
I''m noticing in my weak-o ''spinning cube'' application (not applet) that there are several pauses when the program first starts out, then ever afterwards things Appear OK. A small amount of research turned up that there''s a ''warm-up time'' during which the JVM will spend some time compiling/optimizing the code (at least, as I understand it currently) and this causes brief pauses (for some of ''brief'').
Are there any recommendations on how best to handle this phenomena? I''m a hardcore C++/DirectX guy and I''m not used to having to deal with this (yeah Java newbie trying to Do It All At Once, lol). I''m wondering if this is something that ONLY happens at startup or if I''m going to get this every time newly-executed code runs...
I can think of a couple of things, like having a startup in-engine cutscene that exercises all the mainline code, then switching to the ''real game'' (although this would possibly irritate the player as it''d have to run Each And Every Time the game ran in order to let the optimization/whatever happen).
Comments, URLs, recommendations (other than ''switch languages'' lol) all welcome. I''m somewhat clueless in the Way of the Java despite cramming like an idiot for the past several days!
..wooly..
One big slowdown with JVM start up I run into a lot is massive, up-front class loading. For example: using Swing can set off quite a long chain of class loads depending on what parts of it you''re using.
Otherwise, I would assume what you''re seeing is the start up time for the J3D and JMF subsystems (if I can remember correctly, it was pretty significant for J3D). Try writing small apps to time these startup sequences so you can tell for sure.
Otherwise, I would assume what you''re seeing is the start up time for the J3D and JMF subsystems (if I can remember correctly, it was pretty significant for J3D). Try writing small apps to time these startup sequences so you can tell for sure.
As WayfarerX pointed out, the most common cause of noticeable single-time pauses is the classloader. Since it uses a lazy loading strategy, every time a new class is used, it has to load that class into memory, then link it to everything already loaded.
There are cases where the dynamic compilation has been a factor, but it''s usually not that noticeable.
As far as my recommendation... Ignore it. While you may think there is no similar pause in c++/directX, that''s only partially true. Many games written with that combination stutter slightly at the beginning, as they load more into memory than can fit, and parts of it get paged out. Look at Diablo 2 for an example of that, especially if you alt-tab away from it and then go back to it an hour later. It''s an effect people are used to. As long as performance is good afterwards, people are willing to ignore some stuttering up-front.
There are cases where the dynamic compilation has been a factor, but it''s usually not that noticeable.
As far as my recommendation... Ignore it. While you may think there is no similar pause in c++/directX, that''s only partially true. Many games written with that combination stutter slightly at the beginning, as they load more into memory than can fit, and parts of it get paged out. Look at Diablo 2 for an example of that, especially if you alt-tab away from it and then go back to it an hour later. It''s an effect people are used to. As long as performance is good afterwards, people are willing to ignore some stuttering up-front.
c_wraith, alt-tabbing from an app and forcing page out of resources (by doing other memory intensive stuff for an hour); is very different then having resources being loaded on whim by the VM.
in c++ you can control what gest loaded if you want to. at the start you load directx/opengl and start loading resources. once the resource loading starts you control stutters (to a point). there is no dlls being loaded when they are needed. in all liklyhood the dlls that you reference are already in memory from other apps loading them.
games that stutter at the start are games being run on systems with not enough ram free. there is a point in which its the user causing the problems and not the code. with java many things are automaticly handled. things like garabage collection, class loading, etc. in compiled languages you can ussually load the dlls you want ahead of time. you control when you free memory, since there is no garbage collector. since the code is compiled and optimized already there is no time in which a VM must deal with optimizing the code or compile to native cpu op codes.
the best you can do is to try and forceful load classes that you know you are using manually instead of letting java handle it. i am pretty sure this can be done (have not touched java in a while). as for other problems like the actual code being optmized and compiled as its running, you cant control that. its part of a VM langauge. games like Unreal/UT and quake/quake3 which used VMs could compile when they pleased. the game author controlled the VM thus they coudl force all the code to be compiled at the start.
on a pc with decent ram, things go code. the VM implementation has LOTS to do with things as well. you may wish to try other VMs to see differences. maybe even see what options you can change for the VM in regards to JIT compiling. while JIT is faster it has the "stutter" problem due to code optimization and compiling to native code.
c_wraith is correct in saying that ppl are used to it. just make sure nothing crucial heppens to the player in the first few seconds of a level. though this is why Java has not been used for large realtime interactive apps. its not designed for them, MS pushed that with dx usage in java apps. sun (the creators) wanted it to remain a cross platform system that was meant more for apps that dont care about latency issues.
you coudl try instiating a class of everything you are going to use then deleting them. it may help with class loading thus help reduce the stutter you see.
you could attempt running through the engine code at super speed (ie without actually drawing anything or timing code) so that its compiled and cached already. this could be done while showing a logo for the startpu like all games do. you could use a worker thread at low priority to silently run code and create classes at the start to help cache what is coming up.
my suggesting is to just try to get the classeloader to load things upfront and not deal with other issues since there is not much you can do beyond setting the VM to not do things in that fashion.
in c++ you can control what gest loaded if you want to. at the start you load directx/opengl and start loading resources. once the resource loading starts you control stutters (to a point). there is no dlls being loaded when they are needed. in all liklyhood the dlls that you reference are already in memory from other apps loading them.
games that stutter at the start are games being run on systems with not enough ram free. there is a point in which its the user causing the problems and not the code. with java many things are automaticly handled. things like garabage collection, class loading, etc. in compiled languages you can ussually load the dlls you want ahead of time. you control when you free memory, since there is no garbage collector. since the code is compiled and optimized already there is no time in which a VM must deal with optimizing the code or compile to native cpu op codes.
the best you can do is to try and forceful load classes that you know you are using manually instead of letting java handle it. i am pretty sure this can be done (have not touched java in a while). as for other problems like the actual code being optmized and compiled as its running, you cant control that. its part of a VM langauge. games like Unreal/UT and quake/quake3 which used VMs could compile when they pleased. the game author controlled the VM thus they coudl force all the code to be compiled at the start.
on a pc with decent ram, things go code. the VM implementation has LOTS to do with things as well. you may wish to try other VMs to see differences. maybe even see what options you can change for the VM in regards to JIT compiling. while JIT is faster it has the "stutter" problem due to code optimization and compiling to native code.
c_wraith is correct in saying that ppl are used to it. just make sure nothing crucial heppens to the player in the first few seconds of a level. though this is why Java has not been used for large realtime interactive apps. its not designed for them, MS pushed that with dx usage in java apps. sun (the creators) wanted it to remain a cross platform system that was meant more for apps that dont care about latency issues.
you coudl try instiating a class of everything you are going to use then deleting them. it may help with class loading thus help reduce the stutter you see.
you could attempt running through the engine code at super speed (ie without actually drawing anything or timing code) so that its compiled and cached already. this could be done while showing a logo for the startpu like all games do. you could use a worker thread at low priority to silently run code and create classes at the start to help cache what is coming up.
my suggesting is to just try to get the classeloader to load things upfront and not deal with other issues since there is not much you can do beyond setting the VM to not do things in that fashion.
There is something you can try if you can control the JVM startup... It increases memory usage and startup time immensely, and MAY help with your problem.
Some versions (I think 1.4 and newer, at least) of sun''s JVM have an undocumented option -Xcomp which forces the JVM to compile everything when it''s first loaded. I''m not sure, but it might also force eager classloading, rather than lazy.
It may help. It may not. It''s tough to test with any application I have around.
Some versions (I think 1.4 and newer, at least) of sun''s JVM have an undocumented option -Xcomp which forces the JVM to compile everything when it''s first loaded. I''m not sure, but it might also force eager classloading, rather than lazy.
It may help. It may not. It''s tough to test with any application I have around.
It''s also important to check your memory allocations. If you find that the pauses are when the GC runs you might be best off using the incremental GC ( -Xincgc ) to make it run more in the background.
Just as a FYI, a slight stutter at startup is not bad. If it''s not affecting the normal run of your application I would just ignore it.
Just as a FYI, a slight stutter at startup is not bad. If it''s not affecting the normal run of your application I would just ignore it.
Also, cant you programaticly force pre-loading of classes by doing a Class.forName(String)? Once you put up some sort of notification just place all required classes in try { Class.forName(..) }. That should solve classloader problems.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement