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

[Igor Ignatyev]

Thanks.

Could you please also replace System::exit by throwing an exception?
>  277             System.exit(97);

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
>>>>>>
>>>>>
>>>>
>>>
>