G1 STW phases and FGC column in jstat

Yasumasa Suenaga yasuenag at gmail.com
Thu Mar 3 13:23:54 UTC 2016


Hi all,

I've uploaded PoC of PerfCounter for STW phase in concurrent GC:

   hotspot: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/hotspot/
       jdk: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/jdk/

These patches makes new jstat column CGC and CGCT as below:
-------------
$ jstat -gc 53494 3000
  S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT
  0.0    0.0    0.0    0.0    4096.0    0.0     28672.0      0.0     4480.0 948.9  384.0   77.6       0    0.000   0      0.000   0      0.000    0.000
  0.0   1024.0  0.0   1024.0  3072.0    0.0     28672.0      0.0     4864.0 2969.0 512.0  276.0       1    0.063   0      0.000   2      0.016    0.080
-------------

They are shows STW phase in concurrent GC.

   CMS: Initial Mark and Remark
    G1: Remark and Cleanup

GCT is sum of YGCT, FGCT, and CGCT.


Can be this change accepted?
If so, I will file it to JBS and will send RFR.

I cannot access JPRT.
So I need a sponsor.


Thanks,

Yasumasa


On 2016/03/02 23:19, Yasumasa Suenaga wrote:
> It is not difficult to create webrev for this proposal.
> However, this proposal affects to jstat output, and
> I cannot access JPRT.
> So I want to find sponsor for it at first.
>
> Could somebody be a sponsor?
>
>
> Yasumasa
>
>
> On 2016/03/02 22:29, kirk at kodewerk.com wrote:
>> Hi Yasumasa,
>>
>> It all sounds reasonable and of course the impact on downstream tooling vs the value of the change must be evaluated. In this case I think adding a CGC counter makes sense especially in prep for G1 becoming default in 9.
>>
>> Regards,
>> Kirk
>>
>>> On Mar 2, 2016, at 6:58 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi Kirk,
>>>
>>> Agree to you.
>>> However, I use occasional FGC counter at CMS as below:
>>>
>>> 1. Check major collection occurrence
>>>       Some production systems have large memory as Java heap,
>>>       and they are not set GC log.
>>>       If their CPU usage becomes high, I want to check GC execution.
>>>       (Of course, we have to check any other points :-) )
>>>
>>> 2. Core image analysis
>>>       If JVM is crashed, I want to check PerfCounter to know situation.
>>>       (In the past, I sometimes encountered crash at GC worker thread.)
>>>
>>> I guess that I will want to check them at G1.
>>>
>>> Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
>>> However, this proposal will affect to jstat spec.
>>> So I want to discuss about it before filing to JBS.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/03/02 19:02, kirk at kodewerk.com wrote:
>>>> Hi Yasumasa,
>>>>
>>>> Good question. I’ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I’m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn’t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>>>>
>>>> Regards,
>>>> Kirk
>>>>
>>>>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>
>>>>> Hi Kirk,
>>>>>
>>>>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>>>>
>>>>> Though, how can we check execution of major collection without GC log?
>>>>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>>>>
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>>>>
>>>>>> Regards,
>>>>>> Kirk
>>>>>>
>>>>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>>>>
>>>>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>>>>> What do you think about it?
>>>>>>>
>>>>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>>>>
>>>>>>>
>>>>>>> suggested fix:
>>>>>>> ----------------------
>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>> @@ -103,7 +103,7 @@
>>>>>>>    //   name "collector.1".  In a generational collector this would be the
>>>>>>>    // old generation collection.
>>>>>>>    _full_collection_counters =
>>>>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>>>>
>>>>>>>    // timer sampling for all counters supporting sampling only update the
>>>>>>>    // used value.  See the take_sample() method.  G1 requires both used and
>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>> @@ -230,6 +230,8 @@
>>>>>>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>>>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>>>>    IsGCActiveMark x;
>>>>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>>>>    _cl->do_void();
>>>>>>> }
>>>>>>>
>>>>>>> ----------------------
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>


More information about the serviceability-dev mailing list