JDK-4411600 : Byte buffers significantly slower than arrays in C1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-02-04
  • Updated: 2013-11-01
  • Resolved: 2001-08-08
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.0 beta2Fixed
Related Reports
Relates :  
Description
The following program demonstrates that accessing elements of a byte buffer is
significantly slower with C1 than accessing elements of an array:

    % /usr/local/java/jdk1.4/linux-i386/bin/java -client -showversion BBSpeed
    java version "1.4.0-beta"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b50)
    Java HotSpot(TM) Client VM (build 1.4beta-B50, mixed mode)

    array 225
    array rev 286
    heap 1147
    heap rev 1148
    direct 3301
    direct rev 3304
    % 

I get similar numbers on Solaris (times are in ms).

(The numbers for direct byte buffers are even worse than those for
 heap-allocated byte buffers due to the fact that C1 does not yet inline
 sun.misc.Unsafe operations (4411596).)

Making both heap and direct buffers perform as well as arrays (or nearly so) is
critical to the performance of the java.nio subsystem.

-- mr@eng 2001/2/4


---- BBSpeed.java

import java.nio.*;


public class BBSpeed {

    static final int SIZE = 4096;
    static final int TRIALS = 4096;

    static int sum(ByteBuffer bb) {
	int n = bb.capacity();
	int a = 0;
	bb.rewind();
	for (int j = 0; j < n; j++)
	    a += bb.get(j);
	return a;
    }

    static int sumReverse(ByteBuffer bb) {
	int n = bb.capacity();
	int a = 0;
	bb.rewind();
	for (int j = n - 1; j >= 0; j--)
	    a += bb.get(j);
	return a;
    }

    static int time(String name, ByteBuffer bb) {
	int n = bb.capacity();
	bb.limit(bb.capacity());
	int a = 0;

	for (int i = 0; i < TRIALS; i++) sum(bb);
	long start = System.currentTimeMillis();
	for (int i = 0; i < TRIALS; i++) sum(bb);
	System.out.println(name + " " + (System.currentTimeMillis() - start));

	for (int i = 0; i < TRIALS; i++) sumReverse(bb);
	start = System.currentTimeMillis();
	for (int i = 0; i < TRIALS; i++) sumReverse(bb);
	System.out.println(name + " rev " + (System.currentTimeMillis() - start));

	return a;
    }

    static int sum(byte[] ba) {
	int n = ba.length;
	int a = 0;
	for (int j = 0; j < n; j++)
	    a += ba[j];
	return a;
    }

    static int sumReverse(byte[] ba) {
	int n = ba.length;
	int a = 0;
	for (int j = n - 1; j >= 0; j--)
	    a += ba[j];
	return a;
    }

    static int timeArray() {
	byte[] ba = new byte[SIZE];
	int a = 0;
	
	for (int i = 0; i < TRIALS; i++) a += sum(ba);
	long start = System.currentTimeMillis();
	for (int i = 0; i < TRIALS; i++) a += sum(ba);
	System.out.println("array " + (System.currentTimeMillis() - start));

	for (int i = 0; i < TRIALS; i++) a += sumReverse(ba);
	start = System.currentTimeMillis();
	for (int i = 0; i < TRIALS; i++) a += sumReverse(ba);
	System.out.println("array rev " + (System.currentTimeMillis() - start));

	return a;
    }

    public static void main(String[] args) {
	String key = "hda";
	if (args.length == 1)
	    key = args[0];
	int a = 0;
	if (key.indexOf('a') >= 0)
	    a += timeArray();
	if (key.indexOf('h') >= 0)
	    a += time("heap", ByteBuffer.allocate(SIZE));
	if (key.indexOf('d') >= 0)
	    a += time("direct", ByteBuffer.allocateDirect(SIZE));
	System.exit(a);
    }

}

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004

EVALUATION The numbers have gotten closer since the implementation of the inlining code. We will close this bug after inlining is completed. mohammad.gharahgouzloo@Eng 2001-02-12 I added the inlining and although we have improved in speed by a factore 3 or so. It still does not deal with this bug completely. I am assigning the bug to Mr. Inlining himself for further investigation. There we go Ken. mohammad.gharahgouzloo@Eng 2001-03-08 So far, moe implemented unsafe, ken did the inlining and intrinsified checkindex. We are still not as fast we like. Tom, it is now your turn to make this guy scream... mohammad.gharahgouzloo@Eng 2001-04-19 There's a problem with micro benchmark provided in that since it only runs once, the effects of CHA aren't properly reflected. If you only use DirectByteBuffer or HeapByteBuffer then the get call be inlined but as soon as you load the other class you have to turn it back into a virtual call. I've attached BBSpeed2.java which runs the benchmark twice so that this is apparent. Here are the number for the current c1_baseline on 450Mhz sparc. chimchim /export % /export/ws/c1/jdk1.4/bin/java BBSpeed2 First run: array 341 array rev 347 heap 566 heap rev 579 direct 1437 direct rev 1471 Second run: array 342 array rev 342 heap 1773 heap rev 1796 direct 1780 direct rev 1783 For comparison here are the number for -server from b61. The -client numbers in b61 are much worse so I won't record them here. chimchim /export % /usr/local/java/jdk1.4/solsparc/bin/java -server BBSpeed2 First run: array 68 array rev 67 heap 81 heap rev 91 direct 1012 direct rev 1017 Second run: array 64 array rev 66 heap 1152 heap rev 1356 direct 1495 direct rev 1321 chimchim /export % /usr/local/java/jdk1.4/solsparc/bin/java -server -version java version "1.4.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b61) Java HotSpot(TM) Server VM (build 1.4.0-beta-b61, mixed mode) This doesn't look good for nio performance... thomas.rodriguez@eng 2001-04-19 We've done all can code generation wise for merlin. We could shave maybe 10% but for us that's not worth the potential destabilization of the changes this late in the release. thomas.rodriguez@eng 2001-08-07
07-08-2001