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

[Tobias Hartmann]

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