[9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed: init recursive calls: 51. After deopt 50"
Tobias Hartmann
tobias.hartmann at oracle.com
Wed May 28 09:31:36 UTC 2014
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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140528/12ebfd91/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list