RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests

Christian Thalinger christian.thalinger at oracle.com
Thu Dec 18 22:18:35 UTC 2014


Looks good.

> On Dec 12, 2014, at 12:52 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Thanks, Pavel.
> 
> Best,
> Tobias
> 
> On 11.12.2014 14:41, Pavel Punegov wrote:
>> Igor and Tobias,
>> 
>> thank you for your reviews.
>> I submitted an issue for the nmethod locking:
>> https://bugs.openjdk.java.net/browse/JDK-8067229
>> 
>> On 11.12.2014 10:27, Tobias Hartmann wrote:
>>> Hi,
>>> 
>>> I agree with Igor that concurrent removal of nmethods by the sweeper may be a
>>> problem. I think in 'WB_GetNMethod' we should at least acquire the nmethod lock
>>> (using 'nmethodLocker') to prevent concurrent removal. As far as I understand,
>>> the JNI functions copy the nmethod data. It should be fine for the sweeper to
>>> remove the nmethod afterwards. As a result, the data may be outdated and we
>>> should not expect Whitebox.getNMethod() to always return a NMethod object, even
>>> if the corresponding method was compiled right before.
>>> 
>>> Maybe you can file a separate bug for that issue.
>>> 
>>> Otherwise your change looks good (not a reviewer).
>>> 
>>> Thanks,
>>> Tobias
>>> 
>>> On 10.12.2014 18:59, Pavel Punegov wrote:
>>>> Hi Tobias and Igor,
>>>> 
>>>> could you please review this:
>>>> http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/
>>>> 
>>>> I replaced the check for OSR-methods to skip transitions after deoptimization as
>>>> they may make intermittent failures.
>>>> See 67-70 lines at LevelTransitionTest.java
>>>> 
>>>> I will file a separate RFE to improve this test to be able to check transitions
>>>> after deopt too.
>>>> 
>>>> Testing: jprt, locally
>>>> 
>>>> On 08.12.2014 10:30, Tobias Hartmann wrote:
>>>>> Hi Pavel,
>>>>> 
>>>>> looks good (not a reviewer).
>>>>> 
>>>>> Best,
>>>>> Tobias
>>>>> 
>>>>> On 05.12.2014 21:17, Pavel Punegov wrote:
>>>>>> Hi Tobias,
>>>>>> 
>>>>>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/
>>>>>> 
>>>>>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is
>>>>>> available in the VM it was started with. Then it starts test for
>>>>>> CompilatonPolicyChoice 2 and 3.
>>>>>> 
>>>>>> On 01.12.2014 11:27, Tobias Hartmann wrote:
>>>>>>> Hi Pavel,
>>>>>>> 
>>>>>>> the tests fail with a client VM:
>>>>>>> 
>>>>>>>> Error occurred during initialization of VM
>>>>>>>> Incompatible compilation policy selected
>>>>>>> Please execute them on JPRT to make sure they work on all platforms.
>>>>>>> 
>>>>>>> Best,
>>>>>>> Tobias
>>>>>>> 
>>>>>>> On 28.11.2014 13:27, Pavel Punegov wrote:
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> please review new tests developed as a part of the test task:
>>>>>>>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8059575
>>>>>>>>    webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/
>>>>>>>> 
>>>>>>>> Description:
>>>>>>>> There are two tests to verify level transitions in Tiered Compilation:
>>>>>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues
>>>>>>>> test
>>>>>>>> methods go through common transition patterns:
>>>>>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different
>>>>>>>> trivial methods, and 0 -> 4 after deoptimization.
>>>>>>>> Test provokes compilations of the method and checks that all transitions are
>>>>>>>> correct for CompilationPolicyChoice=2 and 3.
>>>>>>>> 
>>>>>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used
>>>>>>>> for
>>>>>>>> 8056071 (see [*] for details). It checks that all constant getters are
>>>>>>>> always
>>>>>>>> compiled with C1.
>>>>>>>> 
>>>>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590
>>>>>>>> 
>>>>>>>> Testing: done locally
>>>>>>>> 
>> 



More information about the hotspot-compiler-dev mailing list