Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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  
  An important difference twixt server and client VM  (Read 3576 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2003-10-25 12:40:57 »

You have heard many times the mantra "code in <insert apparently inefficient manner> because the JVM <performs some magic optimisation> that makes it free."

Think again, Buster!

Dynamic dead code elimination is not performed by the client VM! Consider this bit of code, like I was the other day:
1  
2  
3  
if (Sys.DEBUG) {
checkGLError();
}

Sys.DEBUG is a static final boolean but it's not known what value it will take until classloading; therefore the java compiler can't simply remove the code during the build.

A few experiments with commenting out the code:
1  
2  
3  
//if (Sys.DEBUG) {
//checkGLError();
//}

and timing it using our hires timer show us that the Hotspot Server VM eliminates it immediately and completely - the commented out code runs at exactly the same speed as the uncommented out code when Sys.DEBUG is false.

The lamentable client VM, on the other hand, retains the check, and executes slower, even though it will always be false. Bah.

Where's my two-stage-compile converged JVM eh??? The client VM is definitely a performance hobbler when you start to do clever stuff that's not actually rendering - like shadow volume calculations and such...

Cas Smiley

Offline leknor

Junior Member




ROCK!!!


« Reply #1 - Posted 2003-10-25 13:04:35 »

Which is why Java 1.4 assertions are not as free as we've been told:
http://wiki.java.net/bin/view/Javapedia/AssertionsAreFreeMisconception
Offline Jeff

JGO Coder




Got any cats?


« Reply #2 - Posted 2003-10-25 21:38:29 »

Quote

Dynamic dead code elimination is not performed by the client VM! Consider this bit of code, like I was the other day:
1  
2  
3  
if (Sys.DEBUG) {
checkGLError();
}

Sys.DEBUG is a static final boolean but it's not known what value it will take until classloading; therefore the java compiler can't simply remove the code during the build.


Umn, I think we need to take a closer look at your benchmark.

While you would *think* this is true, that a static final shouldn't be resovled til runtime, I've always been told that Javac in fact DOES determine static final values from otehr classes by lookup at compile time.

I've had long debates with some oterhs as to whether this is symaticly correct, which is why this statement caught my eye in the first place.

I've been told that pre-resolving static finals is necessary in order to preserve the security structure of the language...

SO I have a strong suspicion you aren't measuring what you think you are...  which is a common failing of microbenchrmarks.

Present your complete benchmark and maybe we can figure out where the result is really coming from.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #3 - Posted 2003-10-26 01:11:31 »

Quote

While you would *think* this is true, that a static final shouldn't be resovled til runtime, I've always been told that Javac in fact DOES determine static final values from otehr classes by lookup at compile time.


That wouldn't work for dynamic values however would it?  For example lets say this boolean random, or maybe true only when the day was a Monday? Or perhaps it was passed in as property (eg.

public static final boolean USE_CACHE = "true".equalsIgnoreCase(System.getProperty("xith3d.cache.transients"));

This topic is currently also being debated in this thread: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1066672655;start=

Will.

Offline Jeff

JGO Coder




Got any cats?


« Reply #4 - Posted 2003-10-26 05:01:38 »

Quote


That wouldn't work for dynamic values however would it?  For example lets say this boolean random, or maybe true only when the day was a Monday? Or perhaps it was passed in as property (eg.

public static final boolean USE_CACHE = "true".equalsIgnoreCase(System.getProperty("xith3d.cache.transients"));


Hmm.  A good point.  That would have to be deferred til run-time assuming its a legal construct. Id really have to take 20 min and program a bunch of quick unambiguos test cases before I'd have a lot of confidence in how it all worked.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2003-10-26 06:49:48 »

It's almost certainly true what I'm saying. The code is very simple and easy to measure:

class X {
void y(int[] value) {
if (Sys.DEBUG) { // Sys.DEBUG cannot be determined until runtime
throw new RuntimeException();
}
value[0] ++;
}
}

X x = new X();
int[] v = new int[1];
long then = Sys.getTime();
for (int i = 0; i < 10000000; i ++) {
x.y(v);
}
long now = Sys.getTime();
System.out.println(v[0]);
System.out.println( (float) (now - then) / (float) Sys.getTimerResolution() );

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2003-10-26 16:43:47 »

Quote

Dynamic dead code elimination is not performed by the client VM!


Oh dear. We checked this with 1.3.x, and have been using static-final-boolean's for debug ever since. I'd assumed that it had worked on both client and server - certainly it *did* work. However, we nerly always use the server VM, and don't guarantee support for the client, so I guess I just didn't pay enough attention when someone told me the results Smiley.

I agree this is very worrying though, since server VM isn't available with JRE Sad.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2003-10-26 16:49:28 »

It's freely distributable separately to the JRE. The real problem is that the server VM is fantastically slow starting up, yet it's the only VM fast enough to compete with C++. There were rumours that the two were going to be consolidated into a two-phase compilation VM a couple of years ago but it's gone quiet since then.

I'm also wondering how other implementations handle it. The Mac port is of particular interest suddenly...

<edit>Just realised you may be thinking about something different to me here: a static final boolean that can be resolved at compile time causes JavaC to eliminate dead code for you. But if it has to wait until classload to determine it - the server VM's the only one that knows how to handle it.

Cas Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2003-10-26 19:22:57 »

Quote
Just realised you may be thinking about something different to me here: a static final boolean that can be resolved at compile time causes JavaC to eliminate dead code for you. But if it has to wait until classload to determine it - the server VM's the only one that knows how to handle it.

Cas Smiley


I was just about to point out that this is the key difference.  Some static finals are known at compile time - in which case the dead code is eliminated before the VM ever sees it.  If the value is established at run time it is a different story.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2003-10-26 22:09:22 »

Quote

 Some static finals are known at compile time - in which case the dead code is eliminated before the VM ever sees it.  If the value is established at run time it is a different story.


Ok I'll bite, how far do you have to go to get the compiler able to strip out the dead code? I assume that a static final within a class will trigger this optimisation within a class, and I guess that a system property as shown before will have to be left until runtime.

But what about constants declared in an external class? What with dynamic class loading and all, does this mean that these must be left until runtime? Thats a real pain if you want to use Sys.DEBUG style flags since to be sure of the compiler doing its magic you'll have to define it in every source file, not just in one global class Shocked

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2003-10-26 23:14:44 »

Will a few if statements really kill your performance anyway?  It's only a few more instructions per frame and a few more bytes in memory after all.

Will.

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2003-10-27 07:19:40 »

Well, yes - because I have been using Sys.DEBUG as freely as I was using assert - right in the middle of my rendering loops, and they've been costing a lot it turns out. That bit of code above executes 30% faster on the client VM when it's commented out.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2003-10-27 16:00:06 »

Quote
Will a few if statements really kill your performance anyway?  It's only a few more instructions per frame and a few more bytes in memory after all.

Will.


In game *servers*, (Cas has already done the client story) you will typically call these more than a hundred thousand times a second, maybe a lot more.

If you have a sensible logging framework, a single logging call is likely to go through several objects and several methods, usually down a filtering chain (have a look at log4J, which IIRC is now part of the standard libs. It's *not* a good logging framework - it's too basic - but it does some things very well. IIRC it has a decent filtering system, allowing you to divert different log-messages to different sinks, multicast them, etc.)

Since your logging framework will tend to be more powerful and complex the more powerful and complex your app/server is, yeah this stuff really matters Sad.

...P.S. you guessed right my mistake Smiley. As it happens, we also actually *only* use class-local vars for this - mainly I expect because of your problem Sad. If I'd found someone who remembered the original results, they'd probably have pointed that out to me in the first place Smiley

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2003-10-27 16:27:42 »

Kinda moot though if you're writing serverside code, because you can then use the server vm anyway which does successfully remove dynamically dead code.

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2003-10-28 01:13:10 »

Quote



<edit>Just realised you may be thinking about something different to me here: a static final boolean that can be resolved at compile time causes JavaC to eliminate dead code for you. But if it has to wait until classload to determine it - the server VM's the only one that knows how to handle it.

Cas Smiley


Ah. Okay, that fits with what I know.

JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2003-10-28 01:15:20 »

Quote
But what about constants declared in an external class? What with dynamic class loading and all, does this mean that these must be left until runtime?


No.

True constants are resolved at comp[iel time.

Yes this DOES mean that the value in use for the constant in one class may NOT match the value in another if they were compield against different versions of the class containing the constant.



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2003-10-28 07:40:25 »

Fortunately I discovered that a long, long time ago Smiley Source of many strange bugs until I realised. More of a problem with command line compilation than IDEs though which recompile all the touched classes automatically.

...any internal news about the "hybrid" two-phase VM...?

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (18 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (23 views)
2014-08-16 06:12:11

Rayexar (63 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!