[9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50"

[Tobias Hartmann]

On 28.05.2014 12:54, Igor Ignatyev wrote:
> Thanks.
>
> Could you please also replace System::exit by throwing an exception?
>>  277             System.exit(97);
>
Done:

http://cr.openjdk.java.net/~anoll/8021775/webrev.03/

Thanks,
Tobias

> Igor
>
> On 05/28/2014 02:45 PM, Tobias Hartmann wrote:
>> Hi Igor,
>>
>> On 28.05.2014 12:32, Igor Ignatyev wrote:
>>> Hi Tobias,
>>>
>>> Since now the test uses JMX, you have to add it into needs_compact3
>>> group in 'test/TEST.groups'.
>>
>> Done. New webrev:
>>
>> http://cr.openjdk.java.net/~anoll/8021775/webrev.02/
>>
>> Thanks,
>> Tobias
>>
>>>
>>>
>>> Igor
>>>
>>> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>>>> Hi Chris,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>>>
>>>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> thanks for the review.
>>>>>>
>>>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>>>> Presumably:
>>>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3,
>>>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>>>            }
>>>>>>> works because we’re using -XX:-BackgroundCompilation, correct?
>>>>>>>  Maybe add a comment there.
>>>>>>
>>>>>> Yes, exactly.
>>>>>>
>>>>>>>  Can we verify via WB API that BackgroundCompilation is off?
>>>>>>
>>>>>> Yes, this is for example done in
>>>>>> CompilerWhiteBoxTest::getVMOption(...) to set 
>>>>>> BACKGROUND_COMPILATION.
>>>>>> But I think because we explicitly disable background compilation in
>>>>>> the test header it should not be possible to re-enable it, right?
>>>>>
>>>>> Correct but who knows what test cleanup might happen in the future.
>>>>>  Maybe someday someone decides that we shouldn’t run tests with
>>>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>>>> couple of issues already.  I want it fool proof.
>>>>
>>>> Right. I added a method backgroundCompilationEnabled(...) to check if
>>>> background compilation is enabled and explicitly check it in main.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>
>>>>>>> I’m happy that using the WB API worked.
>>>>>>>
>>>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch for 8021775.
>>>>>>>>
>>>>>>>> *Problem
>>>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>>>> deoptimization is the same as before by counting the number of
>>>>>>>> possible recursive calls until a StackOverflowException occurs 
>>>>>>>> both
>>>>>>>> before and after deoptimization. The test tries to trigger
>>>>>>>> compilation by executing the method multiple times and enforces
>>>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>>>
>>>>>>>> The test fails on multiple platforms.*
>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>>>
>>>>>>>> *Solution**
>>>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>>>> those points in time where it is needed.
>>>>>>>>
>>>>>>>> I reimplemented the test using the Whitebox API to
>>>>>>>> deterministically trigger compilation and deoptimization.
>>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>>>> *
>>>>>>>> **Tests*
>>>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>>>> fails).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>
>>>>>>
>>>>>
>>>>
>>