[9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100

[Tobias Hartmann]

Thanks, Vladimir.

Best,
Tobias

On 16.10.2014 17:46, Vladimir Kozlov wrote:
> Thank you for explaining, Tobias
> 
> Changes look good.
> 
> Vladimir
> 
> On 10/16/14 2:01 AM, Tobias Hartmann wrote:
>> Hi Vladimir,
>>
>> thanks for the review!
>>
>> On 16.10.2014 03:26, Vladimir Kozlov wrote:
>>> On 10/15/14 1:47 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060454
>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/
>>>>
>>>> Problem:
>>>> The problem is that with a low CompileThreshold we execute the loop to trigger
>>>> osr compilation fewer times. While the
>>>> osr compilation should be triggered there is still a non-osr compilation
>>>> request in the compile queue and therefore the
>>>> osr compilation fails (see 'compilation_is_in_queue(method)' check in
>>>> 'CompileBroker::compile_method_base').
>>>
>>> This is strange. OSR (backbranch count) threshold should be reached before
>>> invocation count threshold. OSR threshold is calculated as invocation threshold
>>> * 1.3 (OnStackReplacePercentage flag). So for 100, OSR threshold should be 130.
>>> Do you know why we get normal compilation in queue? Did we deoptimized first OSR
>>> compilation? In this case osr test is not correct - it should not trigger
>>> deoptimization.
>>
>> Yes, the OSR threshold is reached and an OSR compilation is triggered.
>>
>> The problem is that the warmup code may trigger a non-OSR compilation. To
>> avoid this we deoptimize non-OSR versions
>> after warmup (see line 557/576).
>>
>> We then invoke 'osrMethod' to enforce OSR compilation and this immediately
>> triggers a non-OSR compilation because the
>> threshold was already reached by the warmup code. While we are in the loop
>> (only a short time with a low
>> CompileThreshold) this compilation is still in the queue and blocks an OSR
>> compilation. After loop exit no OSR version
>> is available and the test fails.
>>
>> I think the simplest solution is to just move the deoptimization code inside
>> the OSR triggering methods (as proposed in
>> the webrev). This way we can make sure that there is no non-OSR version
>> available that prevents or blocks OSR compilations.
>>
>> Thanks,
>> Tobias
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Solution:
>>>> I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr
>>>> triggering methods to make sure that no
>>>> non-osr compilation is in the queue after warmup.
>>>>
>>>> Maybe we should think about allowing both osr and non-osr compilations in the
>>>> compile queue at the same time. Currently,
>>>> we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not
>>>> possible to simply add a new flag for osr
>>>> compilations because all bitmasks are taken.
>>>>
>>>> Testing:
>>>> Executed failing tests on JPRT with different VM options (this time including
>>>> -XX:CompileThreshold). Results are
>>>> attached to bug.
>>>>
>>>> Thanks,
>>>> Tobias