Review request (S) 7195557 NPG: Unexpected number of memory pools
bengt.rutisson at oracle.com
Wed Sep 5 11:29:40 UTC 2012
Thanks for the update, Mikael!
On 2012-09-05 12:38, Mikael Gerdin wrote:
> 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:
>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>> 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
>>> My suggested fix is to modify the tests to work with VMs both with and
>>> without perm gen memory pools.
>>> CR link:
>>> 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
>>> With that I'll need someone to sponsor the push since I'm not a
More information about the hotspot-gc-dev