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

Tobias Hartmann tobias.hartmann at oracle.com
Fri May 30 06:58:14 UTC 2014


Roland, Chris, thanks for the reviews.

Best,
Tobias

On 28.05.2014 22:49, Christian Thalinger wrote:
> 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