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

[Niclas Adlertz]

On 2013-09-10 21:06, Vladimir Kozlov wrote:
> It is good.
>
> Vladimir
>
> On 9/10/13 1:49 AM, Niclas Adlertz wrote:
>> On 2013-09-09 11:33, Aleksey Shipilev wrote:
>>> On 09/09/2013 01:16 PM, Niclas Adlertz wrote:
>>>> 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 jump to an address with an offset.
>>>> In fact, tests seem to show the opposite; with a 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).
>>>
>>> Thumbs up. Let's go with your change then.
>>>
>>> -Aleksey.
>>>
>>
>> Thank you Aleksey.
>>

Thank you Vladimir.

Kind Regards,
Niclas Adlertz