After upgrading my computer system some months ago and finishing the port of Tektosyne for Java just recently, I decided it’s time to update the measurements on my comparison page for Oracle’s Java Client and Server VMs on Microsoft Windows.
As a reminder, the core problem is that any modern Windows system should automatically run only the much faster Server VM, just like any modern Unix-based system, but does not because Oracle refuses to even distribute the Server VM with its 32-bit JRE for Windows. So you need to do this yourself.
The updated article, Java Client VM Performance, uses my current hardware and OS (Windows 10 64-bit) throughout, as well as Oracle’s current Java SE 8u112 distribution. Moreover, I added a Tektosyne benchmark (subdivision intersection) to the existing Fibonacci, SciMark, and Star Chess tests.
While my new system is quite a bit faster than the previous test systems, the relative speedup of the Server VMs (both 32 and 64 bit) over the Client VM was so consistent that I did not bother keeping the old test results around. In all tests other than the rather simplistic Fibonacci (where the advantage is greater!), the Server VMs continue to outperform the Client VM by a factor of 1.5–1.6. Meanwhile, startup times are still very similar and as short as to be meaningless for all VMs.
Both Server VMs did exhibit substantially increased memory use, however, and the 64-bit VM has become downright voracious. I don’t know if this was caused by changes in the VMs themselves or in the test environment – I previously used Windows 8.1 rather than 10 – but at any rate there may now be a few more edge cases where one would prefer the Client VM on memory-starved devices. This should not be a concern for the average single-user application on a multi-gigabyte PC, however.
I also updated the download archive that contains the Fibonacci and SciMark tests, and furthermore exemplifies how to bundle the 32-bit Server VM with your application (since Oracle annoyingly refuses to distribute it with the official Windows JRE).
While the JRE has suffered some bloating over the last couple of releases, much of that was due to JavaFX which can legally be removed from redistributed JREs. That done, the total ZIP-compressed size is virtually unchanged – but of course you cannot run JavaFX applications. I can only hope the upcoming module system in Java 9 will quickly lead to smart packaging and smaller distribution sizes.