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

Christian Thalinger christian.thalinger at oracle.com
Wed May 28 20:49:43 UTC 2014


Looks good.  Thanks!

On May 28, 2014, at 4:02 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

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



More information about the hotspot-compiler-dev mailing list