JEP 271: Unified GC Logging - First pre-review
Staffan Friberg
sfriberg at cloudera.com
Tue Oct 27 15:43:08 UTC 2015
Hi,
Looking at the CMS logs I was wondering if we could unify them and make
them more similar to the ParNew. G1 could probably get a similar change.
Quick summary of changes
Add reason
Drop end
Drop start printouts
Add start and end to concurrent phases similar to pause phases
I can see part of the benefit of having a start and end printout for
concurrent phases, you would know that it is running, but the same would
hold true for pauses as well and since we only print a single line for
pauses it might be OK for concurrent phases.
Could potentially be more critical for pauses since the application is
stopped someone (or a script) might actually check the log for what is
going on and find nothing, in a concurrent phase the application is most
likely still execution.
[2.992s][info ][gc] GC#6 GC (Allocation Failure) ParNew end
91M->60M(123M) (2.982s, 2.992s) 10.072ms
[2.994s][info ][gc] GC#7 GC (CMS Initial Mark) end (2.992s, 2.994s)
1.658ms
[2.994s][info ][gc] GC#7 CMS-concurrent-mark-start
[3.180s][info ][gc] GC#7 CMS-concurrent-mark: 0.098/0.186 secs
[3.181s][info ][gc] GC#7 CMS-concurrent-preclean-start
[3.513s][info ][gc] GC#7 CMS-concurrent-preclean: 0.172/0.333 secs
[3.513s][info ][gc] GC#7 CMS-concurrent-abortable-preclean-start
[3.545s][info ][gc] GC#7 CMS-concurrent-abortable-preclean:
0.019/0.032 secs
[3.551s][info ][gc] GC#7 GC (CMS Final Remark) end (3.545s, 3.551s)
5.768ms
[3.551s][info ][gc] GC#7 CMS-concurrent-sweep-start
[5.023s][info ][gc] GC#7 CMS-concurrent-sweep: 0.775/1.472 secs
[5.024s][info ][gc] GC#7 CMS-concurrent-reset-start
[5.024s][info ][gc] GC#7 CMS-concurrent-reset: 0.000/0.000 secs
[2.992s][info ][gc] GC#6 GC (Allocation Failure) ParNew 91M->60M(123M)
(2.982s, 2.992s) 10.072ms
[2.994s][info ][gc] GC#7 GC (Occupancy Limit Hit) CMS-initial-mark
(2.992s, 2.994s) 1.658ms
[3.180s][info ][gc] GC#7 GC (Occupancy Limit Hit) CMS-concurrent-mark
(2.994s, 3.180s) 0.098/0.186 secs
[3.513s][info ][gc] GC#7 GC (Occupancy Limit Hit)
CMS-concurrent-preclean (3.181s, 3.513s) 0.172/0.333 secs
[3.545s][info ][gc] GC#7 GC (Occupancy Limit Hit)
CMS-concurrent-abortable-preclean (3.513s, 3.545s) 0.019/0.032 secs
[3.551s][info ][gc] GC#7 GC (Occupancy Limit Hit) CMS-final-remark
(3.545s, 3.551s) 5.768ms
[5.023s][info ][gc] GC#7 GC (Occupancy Limit Hit) CMS-concurrent-sweep
(3.551s, 5.023) 0.775/1.472 secs
[5.024s][info ][gc] GC#7 GC (Occupancy Limit Hit) CMS-concurrent-reset
(5.024s, 5.024s) 0.000/0.000 secs
//Staffan
On 10/27/2015 08:23 AM, Staffan Friberg wrote:
> Ah, think I got confused by the GC id being printed. I guess that is
> new in JDK 9 EA?
>
> //Staffan
>
> On 10/26/2015 11:13 PM, Bengt Rutisson wrote:
>>
>> Hi Staffan,
>>
>> Thanks for looking at this!
>>
>> On 2015-10-26 18:14, Staffan Friberg wrote:
>>> Just skimmed so far, will give it a more through look.
>>>
>>> Do we want to keep the space after the the Times output? Does it add
>>> any value?
>>> Can bite you sometimes when you grep and look for line endings.
>>>
>>> "[Times: user=0.10 sys=0.00 real=0.02 secs] "
>>>
>>
>> Maybe I was unclear in my email. The logs for PrintGC and
>> PrintGCDetails are the logs for the "old" logging. In the new logging
>> the Times output looks like this:
>>
>> [1.165s][info ][gc,cpu ] GC#1 CPU Times: user=0.39s sys=0.00s
>> real=0.40s
>>
>> Or am I misunderstanding the question?
>>
>> Bengt
>>
>>> //Staffan
>>>
>>> On 10/26/2015 05:26 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi again everyone,
>>>>
>>>> An update on the work for JEP 271 Unified GC Logging.
>>>>
>>>> I now have a working prototype that covers all GCs. Here are some
>>>> examples comparing the old format (using -XX:+PrintGC and
>>>> -XX:+PrintGCDetails) with the new format (using -Xlog):
>>>>
>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/pre-review.00/compare.html
>>>>
>>>>
>>>> The new logging format, using -Xlog, is much more flexible than the
>>>> old format. So, the comparison table on the above page is by no
>>>> means complete. I hope it will give a good overview, but to get a
>>>> real feel for how the new logging works I think it is necessary to
>>>> run locally and play around with the logging options.
>>>>
>>>> Here is a webrev of the changes so far:
>>>> http://cr.openjdk.java.net/~brutisso/JEP-271/pre-review.00/webrev.00/
>>>>
>>>> There is still work to do and I have some known issues with the
>>>> code changes. So, I am currently not asking for too much feedback
>>>> on the actual code changes. I am more looking for feedback on the
>>>> logging behavior. The webrev can be useful to get a feel for what
>>>> the code changes will look like but mostly I think it can be used
>>>> to apply the patch and build your own HotSpot to try out the new
>>>> logging.
>>>>
>>>> Some changes based on the initial feedback:
>>>> - Start and end timestamps for the GC included on the GC log line.
>>>> - Printing the unit of a value without a space. I.e. "10.345ms"
>>>> instead of "10.345 ms". (Still working on fixing this in all places
>>>> as well as trying to use milliseconds instead of seconds in as many
>>>> places as possible.)
>>>> - Printing heap change information with a fixed unit. I am now
>>>> using M for overall heap transition and K for detailed information
>>>> on the debug level.
>>>> - Removed the "summary" tag. Instead the end logging for a GC
>>>> includes all relevant information.
>>>>
>>>> All feedback is very welcome!
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>
More information about the hotspot-gc-dev
mailing list