xxxxx@xxxxx   2001-08-10

J2SE Version (please include all output from java -version flag):

  java version "1.4.0-beta_refresh"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta_refresh-b74)
  Java HotSpot(TM) Client VM (build 1.4.0-beta_refresh-b74, mixed mode)

Does this problem occur on J2SE 1.3?  
  No 

Operating System Configuration Information (be specific):
  Windows NT 4 Workstation, SP6

Bug Description:
  Noticeable is outstanding performance of 1.3.1 Hotspot Client JVM
  and much worse performance of 1.4 Client

Steps to Reproduce (be specific): see attached source

  Run attached Mandelbrot.zip file. Each configuration
  was run 3 or 4 times. All runs on the same config were approximately the
  same except of Merlin server which time to time performed much worse
  then average.

  java -classpath . mandelbrot.Viewer 1200 900

                    16bpp           24bpp

  1.3.1 client        4.6             4.6
  1.3.1 server        8.9             8.9
  merlin_b74 client   9.6             9.6
  merlin_b74 server   7.5 to 14       7.6 to 13.2

  java -classpath . mandelbrot.Viewer 2400 1800

  1.3.1 client        18
  1.3.1 server        34.5
  merlin_b74 client   37.7
  merlin_b74 server   28.8 to 35.9


  Most of the time is spent in method compute() with "raw" computational
  code, without virtual functions and intesive API use.
  That is why diversity of the results is surprising. 

N/A

  xxxxx@xxxxx   has discovered that alignment of doubles in the stack frame on x86
matters a great deal for speed (in particular, for the Mandelbrot benchmark). As
of yet HotSpot does not have a mechanism for guaranteeing doubleword alignment
of stack frames and doubles within them, thus the large discrepancy in run
times.

Changing the benchmark to use single-precision floating-point arithmetic yields
a speed of ~6.0 seconds for the 1.3.1 client and ~5.1 seconds for the 1.4
client.

  xxxxx@xxxxx   2001-08-13

The fix relatively simple.  i've added an interpreter entry point for compiled frames which cause compiled frames to be aligned on double word boundaries.  Then I modified I frame layout code to layout doubles first and then lay the single word locals out.  With these changes the mandelbrot code running on 1.4 runs at the same speed as 1.3.1 no matter whether it's an OSR or normal compile and changing the declaration order of locals has no effect.
  xxxxx@xxxxx   2002-04-12

benchmark of my application
http://homepage1.nifty.com/dangan/Content/Program/Java/jLHA/
LhaSpeed.html
(sorry it's in Japanese)

Marlin's HotSpot ClientVM is slowly.
because JIT compiler works at random.
not compile critical method.
according to my experience,
at worst, marlin is 10times as slow as J2SE 1.3.

This bug seems to be having a large impact on our double
intensive code.  I have noticed that adding a dummy 
local int variable can change the timings of our 
ray-triangle intersection test by a factor of 2.  
Presumably due to altering whether the local double 
variables are 8-byte aligned or not.  I have also
found that this shift can also occur later in the
execution.  Perhaps due to some hotspot dynamic
optimization altering the stack alignment.  This makes
it very hard to get repeatable timings when trying to
optimize my program.

This bug also existed in JDK1.3 and affects any program 
that uses "double" local variables.  I've put a simple java 
file that demonstrates the problem at:

http://www.graphics.cornell.edu/~bjw/javadouble/

It also seriously hampers attempts at optimizing programs 
because the stack alignment side-effects of small code 
changes often cause much larger changes in runtime than the 
improvement (or degradation) directly caused by the change 
in coding.

This is not confined to 1.4; 1.3.1 has the same problem. It's impossible to optimize code systematically, because any change can affect alignment, triggering an unrelated increase or decrease in speed.

Here is another piece of code that exhibits wild difference
in performance of double arithmetics depending on the stack
frame alignment, exccept that it shows several (i.e. more
than two) different levels of performance penalty.

http://www.graphics.cornell.edu/~bjw/javadouble/KriveshkoDoubleTest.html

Thanks to Bruce Walter for hosting the source and the charts
for this example.

Double precision calculations are very important for geographical/terrain modelling calculations.  There are 
*many* important applications of this sort so this bug should be given some priority.

chris thorne

The inconsistency with regard to double calculation
performance makes development of complex applications for
commercial use extremely difficult to tune.  Basically we
have to tell our end-users it's "flaky".  Not exactly a
selling point for J2EE architecture.  We've reproduced the
problem in-house with a very simple program that iterates
the same calculation using float, then double.  By adding
just one float calculation before the double iteration, we
see as much as a 2-fold increase in the time.  And this is
on PIII's with 1.2 Ghz, a far faster system than most of
end-users will have.  Basically, we have no way to benchmark
our performance.  Please fix this bug.

Please fix this bug!!

Can anyone confirm that this has indeed been fixed in 
release 1.4.1 (codenamed 'hopper'), as indicated at the top 
of this bug report?

I cannot find a mention of it in the 1.4.1 Release Notes :(

kenrod:  It's listed as fixed in 1.4.1 here, just do a search on the page for 4490869:

http://java.sun.com/j2se/1.4.1/fixedbugs/141-beta.html