RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation

[Igor Ignatyev]

On 12/09/2014 01:55 AM, Vladimir Kozlov wrote:
> On 12/8/14 11:58 AM, Igor Ignatyev wrote:
>> Vladimir,
>>
>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/
>>
>> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote:
>>> On 12/2/14 1:32 AM, Igor Ignatyev wrote:
>>>> Vladimir,
>>>>
>>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in
>>>> 'non-makeNotEntrant' case, there's no way to determine if the method
>>>> was
>>>> deoptimized.
>>>
>>> I don't understand how you check that in the test.
>> getCompiler returns 0 if method isn't compiled or (in my case) was
>> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a
>> multiplier for result value. if TestCaseImpl::method returns 0, for-loop
>> (lines 75--80) quits.
>
> Okay. I missed that compile() calls method() and returns sum of its
> results.
>
>>
>>>
>>> If you only want to check if method was deoptimized you can check
>>> MethodData::decompile_count().
>>
>> MethodData::decompile_count is incremented only if nmethod is compiled
>> by c2. so it can't be used.
>>>
>>> I don't like extending Unsafe API for just this test.
>> well, I can move it to whitebox, if you don't mind to have intrinsics
>> for it.
>
> I would rather see changes in nmethod and new WB accessors to it.
>
> And sorry, I don't like the test. The test does not have
> comments/description. It is difficult to judge, is it doing what it is
> suppose to do or not.
yeap, sorry. I'll add the comments.

>
> nm->make_not_entrant() will call method()->clear_code(). So how you
> expect that checkCompiled() will not throw Error after deoptimization?:
>
>    69         WHITE_BOX.deoptimizeFrames(makeNotEntrant);
>    70         checkCompiled();
>
> Your loop (lines 75--80) is in a race of compilations vs
> deoptimizations. The test on machines with different numbers of threads
> will behave differently. Where is guarantee that you will get your
> result == 0 case?
> Why do you even need these *concurrent* deoptimization, compilation loops?
> Can you do it synchronously? Execute method in separate thread and stop
> it when you get compilation of requested level or other condition
> (recursion level). Do deoptimization in main thread and see if methods
> are deoptimized.

WB::deoptimizeFrames has to deoptimize methods which are currently on 
stack, that's why I expect that checkCompiled on line 70 won't throw an 
exception and that's why I do need these concurrent 
deoptimization/compilation.

>
> Regards,
> Vladimir
>
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote:
>>>>> Why you need new Unsafe.getCompiler()?
>>>>>
>>>>> thanks,
>>>>> Vladimir
>>>>>
>>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote:
>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/
>>>>>> 220 lines changed: 212 ins; 8 del; 0 mod;
>>>>>>
>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/
>>>>>> 4 lines changed: 4 ins; 0 del; 0 mod;
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> please review the patch which adds
>>>>>>   - a new whitebox method 'deoptimizeFrames' which deoptimizes
>>>>>> methods
>>>>>> which are currently on stack
>>>>>>   - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net
>>>>>> which
>>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly.
>>>>>>
>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595
>>>>>> testing: jprt + new added test
>>>>>>
>>

-- 
Igor