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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 16 15:46:27 UTC 2014


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


More information about the hotspot-compiler-dev mailing list