Review request (S) 7195557 NPG: Unexpected number of memory pools

[Mikael Gerdin]

Thanks for the reviews,
I'll try to get someone here in Stockholm to push this to jdk8 for me.

/Mikael

On 2012-09-06 11:04, David Holmes wrote:
> On 6/09/2012 5:07 PM, Staffan Larsen wrote:
>> Looks good to me, too.
>
> Me too.
>
>> Not a Reviewer, either.
>
> I am :)
>
> David
> -----
>
>> /Staffan
>>
>> On 6 sep 2012, at 08:58, Bengt Rutisson<bengt.rutisson at oracle.com>
>> wrote:
>>
>>>
>>> Thanks, Mikael! I think this fix looks good also when sent out to the
>>> serviceability mailing list :-)
>>>
>>> I am not a JDK reviewer...
>>>
>>> Bengt
>>>
>>> On 2012-09-06 08:54, Mikael Gerdin wrote:
>>>> Somehow serviceability-dev was dropped from the CC list.
>>>> I uploaded a new webrev since I thought Bengt had a point about
>>>> being consistent.
>>>> We talked about where to integrate the fix during the perm gen
>>>> removal meeting and decided that we'd like to push this through
>>>> jdk8/tl/jdk
>>>> since we're not in a rush for the bug fix, it's already marked as a
>>>> known failure.
>>>>
>>>> Can someone from the jdk8 project please Review this fix?
>>>> Thanks
>>>> /Mikael
>>>>
>>>> On 2012-09-05 12:38, Mikael Gerdin wrote:
>>>>> Bengt,
>>>>>
>>>>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Mikael,
>>>>>>
>>>>>> I think this looks good.
>>>>>>
>>>>>> One minor thing. You kind of solved the same problem in two different
>>>>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>>>>> and then increase it if you find a perm gen pool. In
>>>>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged
>>>>>> and
>>>>>> only reduce it if we do not find a perm gen pool.
>>>>>>
>>>>>> I think it would be cleaner to use the same approach for both
>>>>>> tests and
>>>>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>>>>> since the "normal" case from now on should be that there is no
>>>>>> perm gen.
>>>>>
>>>>> Good point, I agree that it looks strange, I've updated the MemoryTest
>>>>> changes to act in a similar way to CollectionUsageThreshold.
>>>>>
>>>>> I've uploaded a new webrev with the updated version:
>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> Bengt
>>>>>>
>>>>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> With the perm gen removal changes the number of memory pools
>>>>>>> exported
>>>>>>> by the VM has changed. This causes the tests
>>>>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
>>>>>>> to fail.
>>>>>>>
>>>>>>> My suggested fix is to modify the tests to work with VMs both
>>>>>>> with and
>>>>>>> without perm gen memory pools.
>>>>>>>
>>>>>>> CR link:
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>>>>
>>>>>>> I'd also like to request that this fix be allowed to be pushed to
>>>>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these
>>>>>>> test
>>>>>>> failures in the hotspot testing before we integrate perm removal
>>>>>>> into
>>>>>>> jdk8.
>>>>>>> With that I'll need someone to sponsor the push since I'm not a
>>>>>>> Committer.
>>>>>>>
>>>>>>> Thanks
>>>>>>> /Mikael
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm