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