First look at JavaFX 1.2, Part II
Check first part here. By just adding -server, I got the following results (standard runs, without removing the toolbar or any other tricks):
- 16 Balls @ 980fps (1% CPU): 1.47X faster than HotSpot Client;
- 128 Balls @ 460fps (14% CPU): 1.39X faster;
- Adaptive mode / 285 Balls @ 200fps (20% CPU): 1.28X more load;
- Adaptive mode / 610 Balls @ 60fps (24% CPU) : 1.08X more load;
HotSpot Server is not adequate for internet deployments or client software: not included in the public JRE, bigger loading time, bigger memory footprint. Typical Server warmup behavior applies: the 16 Balls benchmark (for example) only reaches its maximum score after ~45s of execution. In a real application with a "normal" frame rate, Server might take even more time to fully optimize JavaFX, unless the lower fps is compensated by a more complex scene.
But these results are surprising because I'd think that after JavaFX 1.2's scene graph improvements, JavaFX Ball's performance would already be dominated by native code (FX lays over a good chunk of native libs, from its own runtime and also Java2D's accelerated pipelines). So, we can see interesting potential. Java code in the runtime is still very significant, and maybe the new Scene Graph code (and also Java2D) can be further optimized... Or replaced by even more native code. Sun has already abandoned the PureJava dogma for the JavaFX runtime (the Mobile runtime, apparently, is even more native), so I wouldn't write that off. HotSpot's JIT rules and all, it often delivers C-level code speed, but no bytecode/JIT technology will ever compete with native code for near-zero loading time and minimal memory usage.
[The only reason why competitors like Flash has that split-second loading time is that its runtime is basically a monolithic blob of native code written in C/C++. Flash's managed code (AS3) is not significantly better than Java in loading time, and is just as bad in resource usage and worse in execution performance. Just look at AIR applications, they are every bit as slow-loading and memory-hungry as Swing applets, because AIR's frameworks are written in ActionScript.]
Another possibility is actually using HotSpot Server's superior optimizations... how? Recent builds of HotSpot (in JDK 7 and JDK 6u10+) have a "tiered" execution mode that should combine the best of both worlds: fast startup and lean footprint because most methods are compiled by the Client JIT, but top performance as the really hot methods are (re)compiled by the Server JIT. If this works well, it's another promise of an important boost to the performance of Java desktop software. You can try this with -server -XX:+TieredCompilation, but the implementation is incomplete. This recent OpenJDK thread says it's "in the back burner", apparently with no progress since Steve Goldman, the engineer who was doing it (and to whom we owe other things like the current x64 support), passed away one year ago. The JVM switch works, showing very different compile logs, but the performance is not there; it's not significantly different than pure Server. Several bugs track this feature, and I hope we can get really done in JDK 7 but I think that won't be for FCS as it's clearly not a priority (release driver). Besides that, other improvements of JDK 7, remarkably the Jigsaw modularization, may further improve the loading time of JavaFX (and also Swing) applets.