RFR(M): 8006683: Add WhiteBox API to testing of compiler

[Vladimir Kozlov]

On 2/6/13 10:10 AM, Dmitry Samersoff wrote:
> Vladimir,
>
> Sorry, It looks like I missed something. With argument.cpp changes is
> statement below still correct?

No, Igor have to change his code after Mikael push his changes and I 
asked Igor to wait. New code may look like next (I assume):

   * @library /testlibrary /testlibrary/whitebox
   * @build DeoptimizeAllTest
   * @run main/othervm -Xbootclasspath/a:. 
-XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI DeoptimizeAllTest

Vladimir

>
>> It's needed because a side effect -XX:+WhiteBoxAPI is that wb.jar is
>> appended to the class path, otherwise we wouldn't be able to compile >
> the java sources. Please see the review thread for JDK-8006753 for my
>> attempt to alleviate this problem.
>
> -Dmitry
>
>
> On 2013-02-06 22:04, Vladimir Kozlov wrote:
>> Dmitry,
>>
>> Look on Mikael's fix for 8006753:
>>
>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/
>>
>> Vladimir
>>
>>
>>
>> On 2/6/13 9:43 AM, Dmitry Samersoff wrote:
>>> Mikael,
>>>
>>> Is it better to remove code appending wb.jar from VM
>>> ans use usual classpath setting?
>>>
>>> -Dmitry
>>>
>>>
>>> On 2013-02-06 12:51, Mikael Gerdin wrote:
>>>> Vladimir,
>>>>
>>>> On 2013-02-06 03:17, Vladimir Kozlov wrote:
>>>>> The directories and files layout is good.
>>>>>
>>>>> Why you need to pass -J-XX:+UnlockDiagnosticVMOptions
>>>>> -J-XX:+WhiteBoxAPI
>>>>> to javac (@compile)? javac usually uses Client VM so you will test
>>>>> different VM and it will be hard to diagnose it.
>>>>
>>>> This is due to a shortcoming of the initial implementation of the API.
>>>>
>>>> It's needed because a side effect -XX:+WhiteBoxAPI is that wb.jar is
>>>> appended to the class path, otherwise we wouldn't be able to compile the
>>>> java sources. Please see the review thread for JDK-8006753 for my
>>>> attempt to alleviate this problem.
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> SetDontInlineMethodTest.java also have additional "-cp ./". Why?
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 2/5/13 9:37 AM, Igor Ignatyev wrote:
>>>>>> 1. added new functions:
>>>>>>        public native void    makeMethodNotCompilable(Method method);
>>>>>>        public native int     getMethodCompilationLevel(Method method);
>>>>>> 2. tests were moved to separate files in compiler/whitebox directory
>>>>>> 3. removed redundant '(value ? JNI_TRUE : JNI_FALSE)'
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8006683/webrev.01/
>>>>>>
>>>>>> PS compiler/whitebox/IsMethodCompilableTest fails due to JDK-8007270
>>>>>>
>>>>>> On 01/31/2013 04:28 AM, Vladimir Kozlov wrote:
>>>>>>> On 1/30/13 4:12 PM, Igor Ignatyev wrote:
>>>>>>>> Vladimir, thank you for your feedback.
>>>>>>>>
>>>>>>>>> Could you also add call to get
>>>>>>>>> compilation level code->comp_level() of compiled code?
>>>>>>>> Add this is not a problem, but then we will need to have a copy of
>>>>>>>> enum
>>>>>>>> 'CompLevel' in java code. Or you suggest to return int?
>>>>>>>
>>>>>>> Just int. And may be not for you current test but in one of next to
>>>>>>> check that we have expected comp_level (could be difficult with
>>>>>>> tiered).
>>>>>>>
>>>>>>>>
>>>>>>>>> Do we plan to add more WB tests later as separate *.java tests
>>>>>>>>> or we
>>>>>>>>> keep only one  CompilerWhiteBoxTest.java and update it?
>>>>>>>> I think it's better to write tests as separates file, because it
>>>>>>>> will
>>>>>>>> allow not care about state of counters after previous tests.
>>>>>>>
>>>>>>> Could you then create subdir test/compiler/whitebox for this and
>>>>>>> future
>>>>>>> WB tests?
>>>>>>>
>>>>>>>>
>>>>>>>> During testing of my changes I have found strange behavior of
>>>>>>>> compiler:
>>>>>>>> C1 continues compilation of method even after reaching of
>>>>>>>> recompilation's limit (PerMethodRecompilationCutoff). For C2 (w/o
>>>>>>>> Tiered) all is correct.
>>>>>>>>
>>>>>>>> Is this behavior correct? Or this is a bug?
>>>>>>>>
>>>>>>>> PS Cause of this behavior is calling of 'Method::
>>>>>>>> set_not_compilable()'
>>>>>>>> with argument 'CompLevel_full_optimization' from
>>>>>>>> 'MethodData::inc_decompile_count()', so for C1 the method is still
>>>>>>>> compilable.
>>>>>>>
>>>>>>> File bug. Recently we separated method not-compilable state for C1
>>>>>>> and
>>>>>>> C2, and it is side effect (missed this place).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Igor Ignatyev
>>>>>>>>
>>>>>>>> On 01/30/2013 11:53 PM, Vladimir Kozlov wrote:
>>>>>>>>> Igor,
>>>>>>>>>
>>>>>>>>> I agree with Mikael to give different name to test.
>>>>>>>>>
>>>>>>>>> Calls to get info in VM looks fine to me. Could you also add
>>>>>>>>> call to
>>>>>>>>> get
>>>>>>>>> compilation level code->comp_level() of compiled code?
>>>>>>>>>
>>>>>>>>> Do we plan to add more WB tests later as separate *.java tests
>>>>>>>>> or we
>>>>>>>>> keep only one  CompilerWhiteBoxTest.java and update it?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 1/29/13 12:31 PM, Igor Ignatyev wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review the patch
>>>>>>>>>>
>>>>>>>>>> 1. added new functions to WhiteBox:
>>>>>>>>>>      public native void    deoptimizeAll();
>>>>>>>>>>      public native boolean isMethodCompiled(Method method);
>>>>>>>>>>      public native boolean isMethodCompilable(Method method);
>>>>>>>>>>      public native boolean isMethodQueuedForCompilation(Method
>>>>>>>>>> method);
>>>>>>>>>>      public native int     deoptimizeMethod(Method method);
>>>>>>>>>>      public native boolean setDontInlineMethod(Method method,
>>>>>>>>>> boolean
>>>>>>>>>> value);
>>>>>>>>>>      public native int     getCompileQueuesSize();
>>>>>>>>>>
>>>>>>>>>> 2. added test 'test/compiler/WBApiTest.java' which exercises these
>>>>>>>>>> functions
>>>>>>>>>>
>>>>>>>>>> 3. added result type to macro WB_METHOD_DECLARE
>>>>>>>>>>
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/
>>>
>>>
>
>