[16] RFR(S): 8248552: C2 crashes with SIGFPE due to division by zero
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jul 24 21:41:29 UTC 2020
Good.
Thanks,
Vladimir K
On 7/24/20 4:44 AM, Christian Hagedorn wrote:
> Hi Tobias
>
> Thank you for your review!
>
>> Please make sure to run performance testing.
>
> There is a repeated regression in the micros open crypto benchmark
> openjdk.bench.javax.crypto.small.SecureRandomBench.nextBytes with these two settings:
> - algorithm=SHA1PRNG-dataSize:64-provider:-shared:false
> - algorithm=SHA1PRNG-dataSize:64-provider:-shared:true
>
> Repeated runs with these two settings resulted in a regression between 1 and 2%. I could trace it back to the additional
> type filtering in PhiNode::Value() (webrev.02). This is only required for the assertion code and not for the bailout fix
> itself. When running performance testing with webrev.01, the regressions disappear.
>
> I therefore suggest to go with webrev.01 (without assertion code and type filtering) and file a new RFE to investigate
> the usage of type filtering in PhiNode::Value() for iv phis and why we get a performance regression in these two
> benchmark settings. In theory, I think it should be beneficial to narrow the type range of iv phis.
>
>> cfgnode.cpp:1083
>> - There's an extra whitespace before ","
>>
>> loopopts.cpp:84/86
>> - No need for extra brackets
>
> These are not present anymore in webrev.01.
>
> http://cr.openjdk.java.net/~chagedorn/8248552/webrev.01/
>
> Best regards,
> Christian
>
>
> On 20.07.20 11:14, Tobias Hartmann wrote:
>> Hi Christian,
>>
>> On 15.07.20 15:08, Christian Hagedorn wrote:
>>> http://cr.openjdk.java.net/~chagedorn/8248552/webrev.02/
>>
>> Looks good to me.
>>
>> Some code style comments:
>
>
>> Best regards,
>> Tobias
>>
More information about the hotspot-compiler-dev
mailing list