JEP 271: Unified GC Logging - Second pre-review
bengt.rutisson at oracle.com
Tue Nov 10 08:43:39 UTC 2015
On 2015-11-09 17:46, Kirk Pepperdine wrote:
> Hi Bengt,
>> On Nov 9, 2015, at 10:12 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>> Hi Kirk,
>> On 2015-11-08 00:28, Kirk Pepperdine wrote:
>>> Hi Bernd,
>>> I’m with you that the format stabilization is a great improvement. As far a parsability is concerned, don’t really care were the time stamp sits as long as it’s stable. So having the GCId up front is ok. From my POV, GCID isn’t really all that useful so I’ll most likely ignore it anyways. In general what I’m suggesting can be dropped is stuff I’ll end up ignoring anyways. The way I see it, no point in generating it, stuff it down to disk and storing it if all you’re going to do is ignore it.. but this is what it is so….
>>> What I’d like to see if the date stamp
>> The unified logging framework can give you date stamps as decorations:
>> [2015-11-09T10:10:47.516+0100] GC#35 GC young (G1 Evacuation Pause) 110M->70M(128M) (1.531s, 1.542s) 11.615ms
> This comment relates to another comment about UL decorations. I fully expect that in production environments there will a difference between UL provided timings and the actual time of the event. Same reasoning as to why the time stamps are included in the body (instead of just relying on the UL provided value). No matter.. all I need is one date in the file and then it’s easy enough to calculate the slippage and then all of the other dates for each event.
Should I interpret that as that you are fine with the date information
provided by the decorations? That will give you your date to calculate from.
More information about the hotspot-gc-dev