[ppc] RFR(XS): 8180612: assert failure due to immediate value out of range
lutz.schmidt at sap.com
Fri May 19 19:55:49 UTC 2017
Hi Vladimir, Volker,
Thanks for looking at my fix and your willingness to sponsor it.
I had mentioned that possible x86 issue in the bug description. Maybe that was the wrong place. Anyway, Volker wrote it down here so everyone knows.
On 19.05.2017, 21:02, "Volker Simonis" <volker.simonis at gmail.com> 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,
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.
> 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.
More information about the hotspot-compiler-dev