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

[Vladimir Kozlov]

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.

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.

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
>>>>>
>