Request for Reviews (S): 8007402: Code cleanup to remove Parfait false positive
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Feb 8 19:25:20 PST 2013
David,
I don't see changes to methods declaration in header file regmask.hpp.
Thanks,
Vladimir
On 2/8/13 7:01 PM, David Chase wrote:
>
> Bug: https://jbs.oracle.com/bugs/browse/JDK-8007402
>
> Changes: http://cr.openjdk.java.net/~drchase/8007402/webrev.01/
>
> Problem: very crafty code in regmask.cpp looks like it can read off the end of a buffer, but today, because of the contexts from which it is called, it cannot. So technically not a problem, but Parfait thinks it is a problem, and it might trip someone up in the future or cause them to spend time trying to re-figure-out if it is a problem. This happens in two methods.
>
> Fix: guard the array access.
> Collateral cleanup:
> made "size" parameters const
> removed one redundant assert (now truly redundant with const size parameters)
> slightly clarified one or two comments.
>
> Testing:
> Jtreg compiler (all clean)
> JPRT (all clean)
> Re-ran Parfait on the offending file, it is now clean
> (For diagnostic purposes, re-injected bug to verify that Parfait run-by-me would find it. It did.)
>
> There's a tradeoff between possible efficiency and code cleanliness. The two "easy" ways to solve this are either to add a guard to a sometimes-executed conditional, or two reduce the loop count by one and replicate a customized last-iteration version of the body after the loop. I decided to insert the guard; cache line costs could just as easily do us in, and the added conditional is a non-memory-dependent register compared to a constant, and very easy to speculatively evaluate. No, I did not measure this tradeoff.
>
> David
>
More information about the hotspot-compiler-dev
mailing list