Bug 1358661

Created attachment 1182382 [details]
Example application reproducing the problem (Eclipse project included)

We detected ~10x performance regression in BitSet.valueOf(ByteBuffer) in 1.8.0_20, affecting our production software using 1.8.0_91.

Attached small application demonstrates ~10x performance regression in Java 8
(1.8.0_20) compared to Java 7 (1.7.0_91) and earlier Java 8 (1.8.0_11) in the
ByteBuffer related code (in ByteBuffer.get(int), used by BitSet.valueOf(ByteBuffer)).

By *disabling* tiered compilation via -XX:-TieredCompilation this specific
regression disappears in Java 8 versions >= 1.8.0_20.

Performance in Java 1.7.0_91, Java 8 <= 1.8.0_11 is same independently of the
-XX:TieredCompilation option value.

The regression still exists in all later Java 8 releases (tested with 1.8.0_45,
1.8.0_71, 1.8.0_91, 1.8.0_102).

Unlike to bug JDK-7147227 / JDK-7147987, this is not a regression between Java 6
and Java 7, but a regression between Java 1.8.0_11 and Java 1.8.0_20, and the
performance impact seem to be much higher (it is not 20 - 50% but whooping 1000%).

The application also demonstrates that depending on the *order* of the used API,
performance regression appears on either DirectByteBuffer or HeapByteBuffer API,
but not on both at same time!

The regression shows up in this code snippet (included into a bigger method,
for example BitSet.valueOf(ByteBuffer), where it was initially found):

int n = buffer.remaining();
while (n > 0 && buffer.get(n - 1) == 0) {
	n--;
}

This is the critical part causing performance regression in the BitSet.valueOf(ByteBuffer),
if this API is called alternating with DirectByteBuffer and HeapByteBuffer arguments.

Two important points required to reproduce the regression:
1) Application should use both DirectByteBuffer and HeapByteBuffer, alternating.
If only one argument type is used during the application execution, *no* performance regression occurs.

2) The code in question should be included into a bigger method context.
If the same code snippet is wrapped into a dedicated method and called indirectly,
this does *not* show performance regression:

/* OK */ static int iterateIndirect(ByteBuffer buffer) {
	int n = buffer.remaining();
	while (n > 0 && buffer.get(n - 1) == 0) {
		n--;
	}
	return n;
}

This is neither DirectByteBuffer nor HeapByteBuffer implementation issue, this
must be the issue with the hot spot compiler. The *first* type used in the
computation will show constant performance regression after ~5 iterations.

Since the regression disappears if the tiered compilation is disabled, the problem
seem to be somewhere in the area of C1/C2 compiler interactions/level transitions.

Probably by updating the data for the later compiled subtype C2 somehow kicks out
the already compiled code for another subtype. This would explain why the
execution runs slow for both ByteBuffer types on first iteration (before optimization),
then improves and is fast up to the ~5th iteration for both ByteBuffer types and
then after some compile event it starts to run slow but only for *one* of the
ByteBuffer types, the one, which was used first (and compiled first).

The regression seem timely to correlate with this compilation event:
Iteration 5
    317   27       4       ByteBufferTest::iterateIndirect (27 bytes)   made not entrant
    317   29    b  4       ByteBufferTest::iterateIndirect (27 bytes)

After this event, the performance drops for one of the  ByteBuffer types.

The provided test runs application 4 times with different configurations, which
show the impact of the direct/indirect code use and the impact of the call order
to the regression (the order where either DirectByteBuffer or HeapByteBuffer is
used first).

Run test with:

./run.sh

It will automatically compile the code. Detailed JVM output is saved into 4 log files:
direct.log
directInv.log
indirect.log
indirectInv.log

One can use specific JVM by exporting JAVA_HOME variable:
JAVA_HOME=/usr/lib/jvm/java-1.7.0 ./run.sh
JAVA_HOME=/usr/lib/jvm/java-1.8.0 ./run.sh

One can specify JVM arguments to be used by simply appending them to the end:
./run.sh -XX:+TieredCompilation

Example output for JDK 7 and 8:
logs/execution_log_java7_91.txt
logs/execution_log_java8_11.txt
logs/execution_log_java8_20.txt
logs/execution_log_java8_91.txt
logs/execution_log_java8_102.txt