RFR(XS): JDK-8010941: MinJumpTableSize is set to 18, investigate if that's still optimal

[Niclas Adlertz]

Hi all.

Sorry for the delay.

I've written a JMH test[0] and the results[1] differs from what I previously got. Because of this, I propose the new MinJumpTableSize number to be 10.

WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8010941/webrev01/

[0]
http://cr.openjdk.java.net/~adlertz/JDK-8010941/MyBenchmark.java

[1]
http://cr.openjdk.java.net/~adlertz/JDK-8010941/results.txt

Kind Regards,
Niclas Adlertz


On 22 maj 2013, at 00:48, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 05/21/2013 10:17 PM, Vladimir Kozlov wrote:
> 
>> We usually do about 20000 iterations and run with -Xbatch to make sure
>> tested method is compiled before time measurement.
> 
> Yeah, that works if the benchmark is the single method call. Anything
> more complex require more complex warmup.
> 
>>> Also, I begin to wonder if after the multiply_by_power_of_ten inlining
>>> start to affect how far we unroll the loop, since the jump tables are
>>> starting to be larger.
>> 
>> You can avoid it by
>> -XX:CompileCommand=dontinline,Test::multiply_by_power_of_ten
> 
> Or, (chanting) use JMH:
> http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_16_CompilerControl.java
> 
> Or, (chanting again) use JMH, because it does not really use indexed
> loops, but rather volatile-predicated loop, so the loop unrolling is
> ineffective (double ineffective with the source data re-read from the
> fields on every iteration).
> 
> Before you jump on other platforms, look into the assembly to see if
> your benchmark are actually generate the code that makes sense (i.e.
> trapped on any of the issues Vladimir and me had speculated here):
> https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly
> 
> -Aleksey.