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