G1 STW phases and FGC column in jstat
kirk.pepperdine at gmail.com
kirk.pepperdine at gmail.com
Sun Mar 6 16:03:46 UTC 2016
Hi Yasumasa,
Looks good.
Regards,
Kirk
> On Mar 3, 2016, at 2:23 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>
> 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