SUN fixed this problem a while ago in version 1.4.1, so this page is purely of historical interest. It doesn't apply to current versions of Java.

Double Performance Problem in Java's Hotspot

Plea

If this performance bug affects you, then please vote for bug #4490869 on Sun's java developer website. (A free registration is required if you haven't already registered.) The sooner Sun fixes this, the better it will be for all java programmers who use double variables.

Synopsis

The current version of hotspot (client version) does not enforce the 8-byte alignment of 8-byte quantities, such as doubles, on the stack. It only enforces 4-byte alignment for all quantities. Thus doubles may, or may not, end up being 8-byte aligned depending on what has previously been allocated on the stack by the current and any prior (calling) methods. There is also a significant performance penalty for misaligned double variables (at least on x86 processors and probably most others as well).

Example

I created a small program to demonstrate this bug. Its a simple program that just compute the sum of the first 32 Fibonacci numbers. The tests are repeated and timings are printed for each different method. All the methods use exactly the same technique for generating the Fibonacci numbers; the only difference is how many variables are allocated on the stack and in what order. You can see if your java runtime suffers from this problem by following the intstructions below to run this test program.

Download this java file
Compile and run it, noting the performance
Uncomment the "int dummyInt;" line in the main() method
Compile and run again, noting the changed performance
Use a text editor to replace all instances of "double" with "float"
Compile and run again, noting much more consistent performance this time

Sample Results

Here are some sample results generated using JDK1.4 on a dual 1.7GHz Pentium 4 machine under Windows 2000.

	using floats	using doubles	using doubles (with dummyInt)
computeFib()	1.6s	3.4s	1.3s
computeFibWithFirstInt()	1.6s	3.7s	2.1s
computeFibWithMiddleInt()	1.6s	2.3s	1.7s
computeFibStatic()	1.5s	1.1s	4.3s

There are several things to note in these results:

Performance of the calculations using double varies widely with the simple addition of one extra unused local int variable. Worst case performance change is nearly a factor 4.
Performance of the calculations using floats do not vary widely. Since floats occupy only 4-bytes, 4-byte alignment is sufficient for them
Best case performance with doubles is better than best case performance with floats. Under x86 it actually takes extra work to truncate the precision of the results to float precision.
Average case performance using doubles is significantly worse than using floats because of the performance penalty of the misaligned double variables.
Seemingingly trivial changes to the source code produce radically different performance. This makes it extremely difficult to optimize your code as your never sure if your changes are actually producing more effiicent code or merely changing the stack alignment as a side-effect.

Workarounds

There are several possible workarounds for this problem, but none of them are very appealing

Change all "double"s in your program to "float"s. This is not very appealing for several reasons. One it can take a lot of work. Besides changing all your variable declarations, you will also have to change any double precision constants, and includes casts or changes for any code that communicates with or uses classes beyond the ones you have defined yourself. Moreover, since doubles with proper alignment are faster than floats, this means that once Sun fixes the problem, you will end up with a program that is slower and computes at less precision than if you had done nothing.
Add extra local int variables to manually enforce 8-byte alignment in all your method's stack frames. This would also take a lot of work, be error prone, and is clearly not something that programmers in a high level language should have to do.
Live with performance penalty. The example above is a microbenchmark and one must be very careful about extrapolating to real applications. However in my own double-intensive application, I estimate that this problem can cause my performance to vary by factors of 1.5-2x. It does seem to be a real problem in real code. Losing that much performance is very significant. Moreover the point about this bug making it much harder to optimize ones code because of stack alignment side-effects of code changes, futher complicates my life.
Use the -server option. Sun clearly knows how to fix this problem, because the server runtime "java -server" does not suffer from these performance inconsistencies. Unfortunately at least on my code, the server runtime is much slower than the client runtime. So switching to it only made my program run even slower.

What to do

Try the above program yourself to see if this is a potential problem for you
If it is please, please vote for the bug linked at the top of this page. Sun does pay attention to bug votes and if we can get this bug onto the top-25 list, then we have a much better chance of having Sun fixe this problem sooner rather than later.

Links to related pages

An interesting example sent in by Ilya Kriveshko

This page was written by Bruce Walter, who is solely responsible for its content. You can email comments to me at walter_bruce@hotmail.com