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

[Mikael Gerdin]

Alan,

On 2012-09-05 11:00, Alan Bateman wrote:
> On 05/09/2012 09: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
>>
> It should okay to push this via the hsx/hotspot-gc forest, assuming of
> course that the tests in its jdk repository are actually used for the
> testing that you mention. One thing to know is that
> test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java is
> on the exclude list (see jdk/test/ProblemList.txt) so the test should
> not be run (so in Oracle this means it is excluded in JPRT, in testing
> of jdk8/tl, etc.). If you are happy that the test is now stable then it
> would be good to remove it, but I think you might want to check 7067973
> in case that issue and failure mode still exists.

Good point about looking up where the java/lang/management tests for 
hotspot-gc actually come from. It appears that we pick up the sources 
from the latest promoted build of jdk8 for those tests. So there's 
really no point in pushing the fix to hotspot-gc.
I guess I'll need someone to push this through 8-tl then when it's reviewed.

The nightly testing done on hotspot ignores ProblemList.txt so it's 
still run in our testing. I looked at the recent test execution history 
of CollectionUsageThreshold and I see some timeouts but only when 
running -XX:+UseG1GC and -XX:+ExplicitGCInvokesConcurrent

/Mikael

>
> -Alan.

-- 
Mikael Gerdin
Java SE VM SQE Stockholm