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

[Vladimir Kozlov]

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.

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.

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