[16] RFR(S): 8248552: C2 crashes with SIGFPE due to division by zero

Christian Hagedorn christian.hagedorn at oracle.com
Fri Jul 24 11:44:41 UTC 2020


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