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

[Igor Ignatyev]

On 12/16/2014 03:21 AM, Vladimir Kozlov wrote:
> I am not familiar with Phaser.
> Do I understand correctly that until next line is executed in main thread:
>
> 82         phaser.register();
>
> the method() will not wait - arriveAndAwaitAdvance() calls are nop
> because only one party is registered (in TestCaseImpl() constructor)?
> It allows to execute method() and compile it.
correct + ' phaser.awaitAdvance(phaser.arriveAndDeregister());' 
deregister one of party, so after that, calls of arriveAndAwaitAdvance() 
become "nop" again.

> And I assume "compileonly" prevents inlining of arriveAndAwaitAdvance()
> to avoid unneeded uncommon traps in compiled code.
>
> Looks good in this case. Yes, that is what I wanted.
thank you for review.
>
> Thanks,
> Vladimir
>
>
> On 12/12/14 2:16 PM, Igor Ignatyev wrote:
>> 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
>>>>>>>>>>
>>>>>>
>>>>