[13] RFR (S): 8218758: [TESTBUG] compiler/cha/StrengthReduceInterfaceCall.java misses recompilation event

[Igor Ignatyev]

Vladimir,

in case you are waiting for my response, I'm fine w/ the current state of webrev.00.

-- Igor

> On Feb 12, 2019, at 4:12 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Yes, that's also an option, but I think just ensuring there's a nmethod registered (and keeping existing method if any present) should work fine as well.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 12/02/2019 16:06, Igor Ignatyev wrote:
>> you can use WB.deoptimizeMethod to guarantee the the method is not compiled before the loop.
>> -- Igor
>>> On Feb 12, 2019, at 4:00 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>> 
>>> Thanks, Igor.
>>> 
>>> I made a slight adjustment in the original patch:
>>> 
>>>         public void compile(Runnable r) {
>>> -            assertFalse(WB.isMethodCompiled(TEST));
>>>             while (!WB.isMethodCompiled(TEST)) {
>>> 
>>> If recompilation happens before compile() is called, it would cause problems there as well.
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 12/02/2019 15:52, Igor Ignatyev wrote:
>>>> Hi Vladimir,
>>>> looks good to me.
>>>> Thanks,
>>>> -- Igor
>>>>> On Feb 12, 2019, at 2:07 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>>>> 
>>>>> http://cr.openjdk.java.net/~vlivanov/8218758/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8218758
>>>>> 
>>>>> The test checks that nmethod has been invalidated by ensuring there's no nmethod installed at the moment. But it's not robust enough: it is possible that JVM initiates compilation before the check happens.
>>>>> 
>>>>> The fix is to harden the logic to additionaly check that if there's nmethod installed it differs from the one observed earlier.
>>>>> 
>>>>> Testing: hs-precheckin-comp, tier1-5
>>>>> 
>>>>> Best regards,
>>>>> Vladimir Ivanov