RFR 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Wed Nov 27 13:15:37 PST 2013

Thanks for looking at this, Mandy.

Here is the patch with added explanatory comments - 


On 27.11.2013 21:33, Mandy Chung wrote:
> On 11/27/2013 10:41 AM, Jaroslav Bachorik wrote:
>> Hi,
>> I've uploaded the patch with the minimal changes that should resolve
>> this particular problem.
>> http://cr.openjdk.java.net/~jbachorik/6987597/webrev.04
> Looks good.  I'm happy to see this simple change resolves the issue. It
> would be useful to add a comment before you push to explain why
> -XX:+ExplicitGCInvokesConcurrent flag is used for simplicity even though
> this flag is ignored by non-concurrent GC.
> Mandy
>> -JB-
>> On 22.11.2013 14:57, Jaroslav Bachorik wrote:
>>> On 21.11.2013 17:51, Mandy Chung wrote:
>>>> Hi Jaroslav,
>>>> On 11/19/2013 6:23 AM, Jaroslav Bachorik wrote:
>>>>> Please, review this test fix.
>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6987597
>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6987597/webrev.03
>>>>> The fix moves the execution of the test routine to the
>>>>> GarbageCollectorMXBean notification handler - at that moment it's
>>>>> certain that GC has already happened and it is safe to assert the data
>>>>> provided by the MBean.
>>>> This patch may have a potential issue when GC happens during the
>>>> process
>>>> of adding the notification handlers such as the number of increments is
>>>> greater than the number of registered handlers.   By the time the main
>>>> thread reaches p.arriveAndAwaitAdvance, the phaser has advanced to the
>>>> next phase with few arrived parties and will wait forever (until the
>>>> next GC happens).   This should rarely happen though.  Note that
>>>> p.arriveAndAwaitAdvance continue to run even if the thread is
>>>> interrupted and what happens if jtreg attempts to time out the test?
>>> Thanks for catching this. It seems that using a Semaphore with adding
>>> permissions when a GC notification arrives would be more stable.
>>>> Does this issue only happen to CMS with background GC thread?   The
>>>> proposed patch seems a little overkill.   I wonder if the test should
>>>> skip if running in CMS background mode.  Does
>>>> -XX:+ExplicitGCInvokesConcurrent flag will get System.gc() to run in
>>>> foreground mode in CMS (I think that may get the GC to complete before
>>>> System.gc() returns?)
>>> Yes, currently only CMS. It seems that the semantics of System.gc()
>>> ("When control returns from the method call, the Java Virtual Machine
>>> has made a best effort to reclaim space from all discarded objects.")
>>> doesn't apply to the CMS collector.
>>> Adding "-XX:-ExplicitGCInvokesConcurrent" should force System.gc() to
>>> wait till the GC has been performed. This could help resolve this
>>> particular problem.
>>> -JB-
>>>> Mandy

More information about the serviceability-dev mailing list