These two tests time out frequently in nightly testing in the GC baselines. Here are some examples.

http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-08-23/GC_Baseline-Xconc/vm/linux-amd64/server/mixed/vm-linux-amd64_server_mixed_MM_REGRESSION2007-08-23-21-14-59/java/lang/management/MemoryMXBean/CollectionUsageThreshold.jtr

http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-08-23/GC_Baseline-Xconc/vm/linux-amd64/server/mixed/vm-linux-amd64_server_mixed_MM_REGRESSION2007-08-23-21-14-59/java/lang/management/MemoryMXBean/LowMemoryTest.jtr

From Swamy:

Date: Thu, 23 Aug 2007 18:50:41 -0500
From: Swamy V <###@###.###>
To: Tony Printezis <###@###.###>,
    Serviceability Group <###@###.###>
Subject: Re: MM_REGRESSION

Tony,

Here are my findings related to five MM failures.

1 LowMemoryTest

        Failure mode is timed out.

        AllocaterThread is stuck in while(!listenerInvoked) loop.
                This can happen if the memory threshold has not
        exceeded or no notification listener was not invoked
        from MM. Could be a bug in MM.


2 CollectionUsageThreshold
                Same failure mode as seen with LowMemoryTest and
        looks like a same problem.
                CollectionUsage threshold has not exceeded or
        notification listener was not invoked.

3 & 4. ValidateOpenTypes.java and ProxyTypeMapping.java
                Failed because it returned 0 bytes of committed memory for
        collection usage.
        This may be related to the above two test failures.

Looks like all of the above four problems are related. May be
we have just one problem here.
Similar timeout with CMS and G1 running:

java/lang/management/MemoryMXBean/LowMemoryTest2.sh