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

[Vladimir Ivanov]

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
>