[10] [ppc] RFR(XS): 8180612: assert failure due to immediate value out of range

[Volker Simonis]

Hi Lutz, Vladimir,

@Lutz: thanks for fixing this. I think your change looks good.

@Vladimir: thanks, but I think we can push this ourselves because it
is ppc only.

I've also realized that amd64 uses cmpptr() which takes the result of
"RTMLockingThreshold / RTMTotalCountIncrRate" as an int32_t. This can
be wrong if the result of the division is greater than 32 bit. I'm not
sure how relevant that is, but maybe we could either change the types
of RTMLockingThreshold and RTMTotalCountIncrRate to int or else fix
the compare on amd64 to compare against a full 64 bit value.

What do you think Vladimir - maybe do that as a follow up change or do
you want to include it here (in which case you'd have to sponsor :) ?

Thank you and best regards,
Volker

On Fri, May 19, 2017 at 6:35 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Hi Lutz,
>
> I can sponsor it but someone familiar with PPC have to review the fix.
>
> Thanks,
> Vladimir
>
>
> On 5/19/17 5:45 AM, Schmidt, Lutz wrote:
>>
>> Hi all,
>>
>> May I kindly request reviews for this small fix? A voluntary sponsor would
>> be great as well!
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8180612
>> Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180612.00/
>>
>> The RTM code generation on ppc relied on RTM-related cmdline parameters to
>> provide “well-behaved” values only. At least one jtreg test breaks this
>> assumption. The fix makes code generation adapt to actual parameter values.
>>
>> Thanks,
>> Lutz
>>
>>
>>
>