RFR (XXS): 7110173: GCNotifier::pushNotification publishes stale data.

[Tony Printezis]

Fred,

Thanks for the clarification. You're totally right that the end of the 
individual CMS pauses should not be seen as major GCs.

Tony

On 11/17/2011 9:27 AM, Frederic Parain wrote:
>
>
> On 11/17/11 3:09 PM, Tony Printezis wrote:
>> Fred,
>>
>> 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
>>> satisfactory:
>>> - 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
>> count.
>
> 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.
>
> Fred
>