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

[Igor Ignatyev]

Vladimir,

I rewrote the test to use Phaser. this made the test more robust and 
removed needs for '::getCompiler' method.

http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.02/
211 lines changed: 203 ins; 8 del; 0 mod;

(whitebox class changes)
http://cr.openjdk.java.net/~iignatyev/8028595/top/webrev.00/
1 line changed: 1 ins; 0 del; 0 mod;

Thanks,
Igor

On 12/09/2014 02:44 AM, Vladimir Kozlov wrote:
> On 12/8/14 3:05 PM, Igor Ignatyev wrote:
>> 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.
>
> So you are testing in first lines that if the compiled method does not
> have the frame on stack it will not be deoptimized - *comment* please.
>
> Again. I think the test will be simpler if you execute compiled method
> in a separate thread instead of main where you do all checks.
>
> Vladimir
>
>>
>>>
>>> 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
>>>>>>>>
>>>>
>>