[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -tes
From:       Harsha Wardhana B <harsha.wardhana.b () oracle ! com>
Date:       2016-08-16 8:20:20
Message-ID: 26817096-662d-03f1-b921-c157d6c0562a () oracle ! com
[Download RAW message or body]

Thanks for the Review, Staffan.

-Harsha


On Tuesday 16 August 2016 01:17 PM, Staffan Larsen wrote:
> Ok. Reviewed.
>
> /Staffan
>
>> On 16 aug. 2016, at 08:15, Harsha Wardhana B <harsha.wardhana.b@oracle=
.com> wrote:
>>
>> Yes. assertEQorGTE can be used. But using assertEQorLTE is better suit=
ed as it increase code readability. So I would like to leave that in plac=
e.
>>
>>
>> On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote:
>>> If you swap currUsage and peakUsage in the call to assertEQorLTE() yo=
u can use assertEQorGTE() and you won=92t have to change CodeCacheUtils.j=
ava. Or am I missing something?
>>>
>>>> On 12 aug. 2016, at 17:26, Harsha Wardhana B <harsha.wardhana.b@orac=
le.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review modified webrev incorporating Staffan's comments.
>>>>
>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.01/
>>>>
>>>> Thanks
>>>> Harsha
>>>>
>>>> On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote:
>>>>> Harsha,
>>>>>
>>>>> Thanks for the explanation! With that in mind the new code looks co=
rrect, although I would probably make it even more obvious in which order=
 getUsage() and getPeakUsage() is executed by calling them on separate li=
nes before the call to assertEQorLTE() instead of relying on the order me=
thod parameters are evaluated. Relying on the order of evaluation is corr=
ect, but doing explicit calls would make it a lot more obvious that the o=
rder is important.
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>
>>>>>> On 12 aug. 2016, at 10:07, Harsha Wardhana B <harsha.wardhana.b@or=
acle.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I forgot to put-in the fix details.
>>>>>>
>>>>>> The test was failing because of a race condition caused by the ord=
er in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage w=
as invoked. It is possible that intermediate allocations can happen which=
 can lead to getUsage > getPeakUsage if getUsage is called after getPeakU=
sage. The correct order would be to capture getUsage and then capture get=
PeakUsage in order to account for intermediate allocations.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Harsha
>>>>>>
>>>>>>
>>>>>> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could one of you please review the below fix?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Harsha
>>>>>>>
>>>>>>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote:
>>>>>>>> Please use following alias for compiler tests (hotspot/test/comp=
iler):
>>>>>>>>
>>>>>>>> hotspot-compiler-dev@openjdk.java.net
>>>>>>>>
>>>>>>>> Leonid
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08.08.2016 17:09, Harsha wardhana B wrote:
>>>>>>>>> Gentle Reminder !!
>>>>>>>>>
>>>>>>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote:
>>>>>>>>>> Hello All,
>>>>>>>>>>
>>>>>>>>>> Please review the below simple test fix for the issue,
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345
>>>>>>>>>>
>>>>>>>>>> with webrev located at,
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> Harsha
>>>>>>>>>>

[prev in list] [next in list] [prev in thread] [next in thread]