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

[Schmidt, Lutz]

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. 

Regards,
Lutz

 

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,
    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
    >>
    >>
    >>
    >