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

[Mikael Gerdin]

(adding serviceability-dev again)
Jon

On 2012-09-06 17:05, Jon Masamitsu wrote:
> Mikael,
>
> Does the code in CollectionUsageThreshold.java
> happen to work if perm is the last memory pool
> in the list and the test
>
>   139                 if (result.size() == numMemoryPools) {
>   140                     break;
>   141                 }
>
> exits the loop having never seen perm (so not incrementing
> numMemoryPools?

Good point. I'll have to look at this tomorrow. Unfortunately this 
version of the fix has already been pushed so if we need to fix this 
I'll open a new CR.

/Mikael

>
> Jon
>
> On 09/05/12 23: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