RFR(S): 8008211 : Some of WB tests on compiler fails

[Igor Ignatyev]

On 02/20/2013 12:41 AM, Vladimir Kozlov wrote:
> On 2/19/13 12:12 PM, Igor Ignatyev wrote:
>> There are two different reasons for this failure:
>>
>>     1. with '-Xcomp':
>> CompilerWhiteBoxTest#method() is inlined into #compile() on first
>> invocation of #test(). so 'WHITE_BOX.setDontInlineMethod(METHOD, true)'
>> does nothing; #method() isn't compiled;
>
> You need to make method() more complex to avoid it. Currently it is
> treated as an "accessor" method and it is inlinined unconditionally. For
> example, pass argument and return increment (x+42).
> I don't see how moving WHITE_BOX.setDontInlineMethod() helps.

moving WHITE_BOX.setDontInlineMethod(METHOD, true) helps because it 
disallow inlining of METHOD.

cutting of PrintInlining/PrintCompilation output before moving:

    3716  615    b  3       DeoptimizeAllTest::test (35 bytes)
                               @ 7 
sun.hotspot.WhiteBox::setDontInlineMethod (0 bytes)   native method
                               @ 12   CompilerWhiteBoxTest::compile (26 
bytes)
                                 @ 13   CompilerWhiteBoxTest::method (3 
bytes)
                               @ 19 
CompilerWhiteBoxTest::checkCompiled (122 bytes)   callee is too large
                               @ 25 
sun.hotspot.WhiteBox::deoptimizeAll (0 bytes)   native method
                               @ 31 
CompilerWhiteBoxTest::checkNotCompiled (75 bytes)   callee is too large

and after moving:
    3983  616    b  3       DeoptimizeAllTest::test (24 bytes)
                               @ 1   CompilerWhiteBoxTest::compile (26 
bytes)
                                 @ 13   CompilerWhiteBoxTest::method (3 
bytes)   don't inline by annotation
                               @ 8   CompilerWhiteBoxTest::checkCompiled 
(122 bytes)   callee is too large
                               @ 14 
sun.hotspot.WhiteBox::deoptimizeAll (0 bytes)   native method

>>     2. with '-XX:+TieredCompilation' and certain relation between
>> 'CompileThreshold' and 'Tier*' values (e.g. -XX:CompileThreshold=100 and
>> default Tier* values):
>> since 'CompileThreshold' doesn't use in Tiered as threshold, but uses in
>> tests we have situation in which CompilerWhiteBoxTest#compile() invokes
>> #method() insufficient time for compilation;
>
>
> With Tiered the default threshold for first tier (C1) is 100. Yes, for
> C2 it is >10000 and depends on other staff. But COMPILE_THRESHOLD=10000
> should be enough for tier one compilation. So I don't understand what do
> you mean by "invokes insufficient time for compilation".

in current version of tests value of 'CompileThreshold' is used as limit 
in for-loop. In nightly it equals '100' and it isn't enough even for 
tier one, cuz with default values of Tier* flags we need to invoke 
method 256 times.
in attachment program that illustrates it:

$ java -XX:+PrintCompilation -XX:+TieredCompilation 
-XX:CompileThreshold=100 -XX:+PrintTieredEvents CompileThresholdTest 100 
| grep CompileThresholdTest

$ java -XX:+PrintCompilation -XX:+TieredCompilation 
-XX:CompileThreshold=100 -XX:+PrintTieredEvents CompileThresholdTest 256 
| grep CompileThresholdTest
0.049705: [call level: 0 [CompileThresholdTest.m1()I] @-1 queues: 0,0 
rate: n/a k: 1.00,1.00 total: 128,0 mdo: 0(0),0(0) max levels: 0,0 
compilable: c1, c2, osr status: idle]
0.049785: [call level: 0 [CompileThresholdTest.m1()I] @-1 queues: 0,0 
rate: n/a k: 1.00,1.00 total: 256,0 mdo: 0(0),0(0) max levels: 0,0 
compilable: c1, c2, osr status: idle]
0.049812: [compile level: 3 [CompileThresholdTest.m1()I] @-1 queues: 0,0 
rate: n/a k: 1.00,1.00]
      49    8       3       CompileThresholdTest::m1 (3 bytes)


> And I really don't like next code:
>
> !         int count = getCompileThreshold();
> !         int i = 0;
> !         do {
> !             for (; i < count; ++i) {
>                    result += method();
>                }
> +             count = getCompileThreshold();
> +         } while (i < count);
>
> You are using in getCompileThreshold() the knowledge of current tiered
> threashold implementation.  But it could be changed in a future.
>

I would like to pull out getting of tiered threshold to WB, but I could 
not find a way to do this, since we have only predicate to test + 
'Tier0InvokeNotifyFreqLog' determines how often predicate will be checked.

> Vladimir
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 02/19/2013 10:49 PM, Vladimir Kozlov wrote:
>>> Igor,
>>>
>>> Can you give mode details about the failure?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 2/19/13 9:37 AM, Igor Ignatyev wrote:
>>>> Hi all,
>>>>
>>>> Please review the patch.
>>>>
>>>> 1. calls of WB.setDontInlineMethod() were moved into main()
>>>> 2. added estimation of threshold for tiered compilation
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8008211/webrev.00/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CompileThresholdTest.java
Type: text/x-java
Size: 307 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130220/175fe958/CompileThresholdTest.java