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

[Vladimir Kozlov]

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/