JDK-4851535 : {Float,Double}Buffer performance regression
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-04-21
  • Updated: 2003-04-29
  • Resolved: 2003-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 b22Fixed
Related Reports
Relates :  
Description
There appears to have been a change in either the JAWT or the default AWT Canvas
properties on Windows in 1.4.2 (not present in 1.4.1_02) that is causing severe
performance degradation of Java applications using OpenGL through e.g. the
GL4Java library.

To reproduce, extract the attached archive. Add the jar files to your classpath
and place the .dll in your path. javac VertexArrayRange.java ;
java VertexArrayRange. Requires an NVidia GeForce family card, though the code
path in the demo which doesn't use the NVidia-specific extension also shows a
significant slowdown relative to 1.4.1_02.

The slowdown isn't affected by either the -Dsun.java2d.noddraw=true or
-Dsun.java2d.d3d=false flags. It also isn't affected by setting vs. not setting
the GraphicsConfiguration of the created Canvas (GL4Java's GLAnimCanvas class
subclasses Canvas).

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-rc tiger FIXED IN: mantis-rc tiger INTEGRATED IN: mantis-b22 mantis-rc tiger tiger-b07
14-06-2004

WORK AROUND None found yet except to revert to 1.4.1_02. This is why the priority has been placed high; would otherwise have filed as P4.
11-06-2004

EVALUATION Thanks to ###@###.###, ###@###.###, and most importantly the Java2D build archives maintained by ###@###.###, have isolated this to a performance regression in FloatBuffer and DoubleBuffer introduced during the fix for 4804304. The root cause is the conversion of float <-> int and double <-> long in the direct buffer case where byte swapping is not needed. As a specific example, the generated sources in e.g. DirectFloatBufferU.java currently look like public FloatBuffer put(int i, float x) { unsafe.putInt(ix(checkIndex(i)), (Float.floatToRawIntBits(x))); return this; } where they should look like public FloatBuffer put(int i, float x) { unsafe.putFloat(ix(checkIndex(i)), x); return this; } All of the get and put operations in the template files need to be conditionalized on whether byte swapping is being done when deciding whether to perform float <-> int and long <-> double conversions. The attached FloatBufferPerformanceRegression.java illustrates the factor of 5 to 6 performance slowdown incurred by the unneeded conversion. This occurs on both SPARC and x86 with both the client and server compilers so the priority has been raised. ###@###.### 2003-04-21 Since the fix for 4804304 was apparently backported to 1.4.1_03 the fix for this bug will need to be brought back as well. ###@###.### 2003-04-21
21-04-2003

SUGGESTED FIX The webrev attached to this bug report describes the fix that will be integrated into mantis-rc. For convenience it is also available online at http://nio.sfbay/rev/4851535/. -- ###@###.### 2003/4/23
04-11-0189