[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-use
Subject:    GC_Locker turning CMS into a stop-the-world collector
From:       Y.S.Ramakrishna () Sun ! COM (Y !  Srinivas Ramakrishna)
Date:       2010-01-25 19:58:08
Message-ID: 4B5DF7D0.7090601 () sun ! com
[Download RAW message or body]

Thanks to Chi Ho's observation that -XX:+ExplicitGCInvokesConcurrent
is essential to reproduce the problem. I now know _exactly_ the
root cause of the problem. A fix will be made in the near future.
The bug report will be updated. Thanks again to chi Ho for the test
case and the crucial observation that led to the diagnosis
of the problem.

over and out.
-- ramki

Y. Srinivas Ramakrishna wrote:
> Just a very quick update on this. Chi Ho and i have been
> communicating off-line on this yesterday and today,
> and i filed:-
> 
>     6919638 CMS: NIO-related performance issue, gc locker implementation suspected
> 
> and have updated it with what we know so far (the updates
> appear somewhat delayed at bugs.sun.com).
> 
> what is known so far is that the problem is mitigated in
> jdk 7 because the array copies are broken down into
> smaller critical sections; as a result the test case
> does not exhibit the blocking behaviour on jdk7.
> Not so in jdk 6uXX where the array copies occur in
> a single critical section, and the blockage is easily
> reproducible.
> 
> What is not yet clear to me (although i am looking
> into it) is why the blockages seem to coincide with CMS
> background collections. Investigation ongoing, and
> the bug report will be kept updated as we find out more.
> 
> Chi Ho's latest test case (attached to the bug report) was
> crucial in quickly reproducing the reported problem (thanks, Chi Ho!).
> -- ramki
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


[prev in list] [next in list] [prev in thread] [next in thread]