Request for review (XXS): 7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently

[Bengt Rutisson]

Hi again,

A quick update on this. I ran the following tests using UTE on a Linux 
x64 host just to make sure that my change doesn't break any other part 
of the management API.

java/lang/management
com/sun/management
sun/management
vm.tmtools.testlist
nsk.monitoring.testlist

I did see some intermittent failures of  
java/lang/management/ThreadMXBean/ResetPeakThreadCount.java, but I think 
that is:

6766097: TEST_BUG: ResetPeakThreadCount fails because it does not join 
threads

Other than that all tests pass. This includes 
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java that 
used to fail.

Bengt

On 2012-05-31 22:04, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I have a couple of reviews for this really small change?
> http://cr.openjdk.java.net/~brutisso/7067973/webrev.00/
>
> Background:
> The CollectionUsageThreshold test fails with G1. The test lowers the 
> notification threshold for the G1 old gen memory pool and expects to 
> get a notification after a full GC.
>
> The problem in G1 is that the decision to send the notification is 
> done in TraceMemoryManagerStats::~TraceMemoryManagerStats(). This 
> eventually does pool->get_memory_usage() to get the memory usage after 
> a collection. The problem is that we update this information in 
> G1MonitoringSupport::update_sizes() which is called in 
> G1CollectedHeap::do_collection() _after_ the TraceMemoryManagerStats 
> scope had been exited.
>
> Extending the scope to cover the call to 
> G1MonitoringSupport::update_sizes() solves the issue.
>
> Testing:
> Before this change the CollectionUsageThreshold failed every time I 
> ran it. After this change it passes every time I ran it.
>
> Thanks,
> Bengt