[9] RFR(S): 8072398: assert fails in L1RGenerator::increment_event_counter_impl

[Igor Veresov]

The code looks good. But I think the comment about CompileThresholdScaling == 0 being equivalent to -Xint is bit misleading. The VM does not become interpreter-only, does it?

igor

> On Feb 5, 2015, at 8:18 AM, Zoltán Majó <zoltan.majo at oracle.com> wrote:
> 
> Hi,
> 
> 
> please review the following small patch.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072398
> 
> Problem: The reported assert is triggered because the method LIRGenerator::increment_event_counter_impl is called with parameter 'frequency' set to -1.
> 
> The value originates from Arguments::scaled_freq_log(): If both variables 'freq_log' and 'scale' are small, 'scaled_freq' can become 0 and the function log2_intptr returns -1 for the value 0. A similar problem appears if freq_log == 0.
> 
> 
> Solution:
> 
> To treat the above mentioned cases graciously, this patch:
> 
> - Changes Arguments::scaled_freq_log() and Arguments::scaled_compile_threshold() to allow scaling the frequency/threshold by 0.0 and return 0.0 in these cases without calling log2_intptr().
> 
> - Adds a new condition to Arguments::set_tiered_flags(): Threshold values are *not scaled* if 'CompileThresholdScaling' is 0.0 (behavior equivalent to -Xint). Previously, this functionality was encoded in scaled_freq_log() and scaled_compile_threshold(). Handling this case in set_tiered_flags() results in clearer code.
> 
> - Improves comments.
> 
> 
> Webrev: http://cr.openjdk.java.net/~zmajo/8072398/webrev.00/
> 
> Testing:
> - manual testing with failing test cases
> - compiler/arguments/CheckCompileThresholdScaling.java
> - JPRT
> 
> Thank you and best regards,
> 
> 
> Zoltan
>