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

[Vladimir Kozlov]

Thank you, Volker

I think all RTM tuning flags should be uint (unsigned 32bit int).
We did not have int/uint types when RTM was implemented. They were added 2 years ago:

http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8597e296c18b

Lets change type of RTM flags in all places. I will review and sponsor.

thanks,
Vladimir

On 5/19/17 12:02 PM, Volker Simonis wrote:
> 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
>>>
>>>
>>>
>>