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

[Niclas Adlertz]

On 2013-09-06 14:02, Aleksey Shipilev wrote:
> On 09/06/2013 03:54 PM, Niclas Adlertz wrote:
>>> 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.
> Sure, any time.
>
>>> 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/
> Good!
>
> I worry about the 32-bit x86 though. It seems the register pressure with
> jump tables is higher? If so, the turn-point for x86 can be even larger.
> Can you double-check the 32-bit x86 VM?
>
> -Aleksey.
>
Hi Aleksey.

I don't think the register pressure is higher using a jump table since 
it's just a jumpto an address with an offset.
In fact, tests seem to show the opposite; witha lookup table 
(implemented as a binary search) fewer registers seem to have a negative 
impact.
When we have 6 cases, it's actually faster to use a jump table on 32-bit 
x86 instead of a lookup table (compared to 10 on x64).

See details below.

Kind Regards,
Niclas Adlertz


32-bit x86 results:

Loss 4: (Slower to use jump table for 4 cases)
Using jump table:
   Run result "switch_calculation": 73241.726 ?(95%) 108.393 ?(99%) 
148.167 ops/msec
   Run statistics "switch_calculation": min = 72531.327, avg = 
73241.726, max = 73430.545, stdev = 231.605
   Run confidence intervals "switch_calculation": 95% [73133.332, 
73350.119], 99% [73093.559, 73389.893]
Not using jump table:
   Run result "switch_calculation": 74003.870 ?(95%) 14.847 ?(99%) 
20.294 ops/msec
   Run statistics "switch_calculation": min = 73915.288, avg = 
74003.870, max = 74054.011, stdev = 31.723
   Run confidence intervals "switch_calculation": 95% [73989.023, 
74018.717], 99% [73983.575, 74024.164]

Win 6: (Faster to use a jump table for 6 cases)
Using jump table:
   Run result "switch_calculation": 63024.440 ?(95%) 78.005 ?(99%) 
106.628 ops/msec
   Run statistics "switch_calculation": min = 62556.438, avg = 
63024.440, max = 63217.447, stdev = 166.675
   Run confidence intervals "switch_calculation": 95% [62946.435, 
63102.446], 99% [62917.812, 63131.069]
Not using jump table:
   Run result "switch_calculation": 61020.470 ?(95%) 41.714 ?(99%) 
57.020 ops/msec
   Run statistics "switch_calculation": min = 60818.606, avg = 
61020.470, max = 61156.266, stdev = 89.130
   Run confidence intervals "switch_calculation": 95% [60978.756, 
61062.184], 99% [60963.450, 61077.490]

Win 10: (Faster to use a jump table for 10 cases)
Using jump table::
   Run result "switch_calculation": 59974.581 ?(95%) 15.652 ?(99%) 
21.395 ops/msec
   Run statistics "switch_calculation": min = 59941.809, avg = 
59974.581, max = 60062.017, stdev = 33.444
   Run confidence intervals "switch_calculation": 95% [59958.929, 
59990.233], 99% [59953.186, 59995.977]
Not using jump table:
   Run result "switch_calculation": 53834.572 ?(95%) 118.519 ?(99%) 
162.009 ops/msec
   Run statistics "switch_calculation": min = 52796.338, avg = 
53834.572, max = 53934.257, stdev = 253.242
   Run confidence intervals "switch_calculation": 95% [53716.052, 
53953.091], 99% [53672.563, 53996.580]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130909/a2b5fa01/attachment-0001.html