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

[Vladimir Kozlov]

Good. Please, do JPRT test run with -rtests compiler/whitebox

Thanks,
Vladimir

On 2/7/13 12:11 PM, Igor Ignatyev wrote:
> I have updated the patch with removing unnecessary "-cp ./"
>
> http://cr.openjdk.java.net/~iignatyev/8006683/webrev.02/
>
> Best regards,
> Igor Ignatyev
>
> On 02/06/2013 11:01 PM, Vladimir Kozlov wrote:
>> On 2/6/13 10:56 AM, Mikael Gerdin wrote:
>>> Vladimir,
>>>
>>> On 2013-02-06 17:41, Vladimir Kozlov wrote:
>>>> Igor, Mikael explained it. I think you need to wait when his are
>>>> changes
>>>> pushed.
>>>
>>> If it's ok with you I'd rather wait for the NMT WhiteBox additions and
>>> Igor's compiler additions to the API to get pushed and propagate through
>>> the repos and then merge those changes into mine and push my changes.
>>
>> It is fine with me.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> /Mikael
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 2/6/13 12:52 AM, Igor Ignatyev wrote:
>>>>>> 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.
>>>>>
>>>>> Because these flags are needed for adding wb.jar to classpath, w/o
>>>>> them
>>>>> javac could not find sun.hotspot.WhiteBox:
>>>>>
>>>>> test/compiler/whitebox/MakeMethodNotCompilableTest.java:38: error:
>>>>> cannot access WhiteBox
>>>>>          if (!WHITE_BOX.isMethodCompilable(METHOD)) {
>>>>>                        ^
>>>>>    class file for sun.hotspot.WhiteBox not found
>>>>> 1 error
>>>>> result: Failed. Compilation failed: Compilation failed
>>>>>
>>>>>
>>>>>> SetDontInlineMethodTest.java also have additional "-cp ./". Why?
>>>>> my oversight
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 02/06/2013 06:17 AM, 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.
>>>>>>
>>>>>> 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/