RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data.
tony.printezis at oracle.com
Thu Nov 17 06:39:29 PST 2011
Thanks for the clarification. You're totally right that the end of the
individual CMS pauses should not be seen as major GCs.
On 11/17/2011 9:27 AM, Frederic Parain wrote:
> On 11/17/11 3:09 PM, Tony Printezis wrote:
>> I haven't been following this thread closely, but I do have a question
>> (see below).
>> On 11/17/2011 8:43 AM, Frederic Parain wrote:
>>> Hi Mandy,
>>> It would have been nice to have notifications providing
>>> detailed information about CMS different phases, but it
>>> doesn't seem easy to do right now. I did the experiments
>>> with CMS using JConsole, and the result is not really
>>> - several notifications are sent for each CMS cycle
>>> but the notification lacks the information to identify
>>> the CMS phase associated with the notification (worse
>>> than that, they all claim they notify the "end of a major
>>> GC cycle" which is certainly not true for CMS.
>> Are you referring to notifications at the end of a concurrent cycle
>> (i.e., at the end of sweeping)? Depends on how you look at it, but a
>> concurrent cycle is a major cycle given that it collects the entire
>> heap. In fact, IIRC, the a concurrent cycle should increase the full gc
> I'm not referring to the concurrent cycles, but to the different phases
> of CMS. It seems that CMS is calling GCMemoryManager::gc_end() after
> the initial marking, the final marking and the sweeping phase. The
> gc count (_num_collections) is incremented only after the completion of
> the sweeping phase. The actual notification code is confused
> by the fact that CMS is executing GCMemoryManager::gc_end() several
> times during a GC cycle. I made the assumption that calling gc_end()
> means that the GC cycle is completed, but this assumption is wrong
> with CMS, so the notification message is wrong in this case.
More information about the hotspot-gc-dev