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

Christian Thalinger christian.thalinger at oracle.com
Fri May 16 16:00:14 UTC 2014


On May 16, 2014, at 4:29 AM, Tobias Hartmann <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.

> 
> 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> 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/20140516/46c842c4/attachment.html>


More information about the hotspot-compiler-dev mailing list