Review request (S) 7195557 NPG: Unexpected number of memory pools
Mikael Gerdin
mikael.gerdin at oracle.com
Wed Sep 5 10:38:50 UTC 2012
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
More information about the hotspot-gc-dev
mailing list