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

[Niclas Adlertz]

Hi Aleksey.

> It is customary for us (perf guys) to create multiple
> @GMB methods with different problems sizes, and run them in single JMH
> session.
That would have been smarter, yes. I'll do that next time. Thanks.
And thank you for helping me with JMH. 

> Yes, "10" seems the turn-point for X64; for SPARC, I'd set it to "5".
Ok, I'll have one value for each platform instead. 

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

Kind Regards,
Niclas Adlertz


On 6 sep 2013, at 10:03, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 09/05/2013 06:59 PM, Niclas Adlertz wrote:
>> I'll give an example:
>> LOSS: At 3:
>>  Using JumpTable:
>>    Run result "switch_calculation": 166204.989 ±(95%) 52.012 ±(99%) 71.097 ops/msec
>>    Run statistics "switch_calculation": min = 166105.218, avg = 166204.989, max = 166602.390, stdev = 111.134
>>    Run confidence intervals "switch_calculation": 95% [166152.977, 166257.000], 99% [166133.892, 166276.085]
>>  Not:
>>    Run result "switch_calculation": 204049.471 ±(95%) 119.901 ±(99%) 163.897 ops/msec
>>    Run statistics "switch_calculation": min = 203408.606, avg = 204049.471, max = 204390.380, stdev = 256.193
>>    Run confidence intervals "switch_calculation": 95% [203929.570, 204169.372], 99% [203885.574, 204213.368]
>> 
>> Here, we have tried a switch statement with 3 cases (hence "3") and we lose performance by using a jump table (hence "LOSS"). 
>> When we use a jump table ("Using JumpTable") we get the score 166204.989 ops/msec, but when we don't use jump tables ("Not") we can do more ops/msec, 204049.471. 
> 
> I get it now, thanks! I was partially confused because the benchmark
> only had 16 cases. It is customary for us (perf guys) to create multiple
> @GMB methods with different problems sizes, and run them in single JMH
> session.
> 
> Yes, "10" seems the turn-point for X64; for SPARC, I'd set it to "5".
> 
> -Aleksey.