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

[Vladimir Kozlov]

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/