JEP 271: Unified GC Logging

Bengt Rutisson bengt.rutisson at oracle.com
Fri Sep 25 08:50:32 UTC 2015


Hi Kirk,

On 2015-09-25 09:30, Kirk Pepperdine wrote:
> Hi Benqt,
>
> I have one question. Is there a reason that the logging is reported in units of 0.1M instead of K. I ask only because I sometimes find that resolution leads to some significant rounding errors in my calculations. Can we move to have it report either in K or just plain bytes.

I think the reason is that it is nice to have a common unit and it was 
probably thought that megabytes was enough for many use cases. The 
different GCs use different approaches for the memory units. I currently 
don't have any plans on fixing that as part of my initial pass on the GC 
logging. But that is a good thing to look at as a second step. I'd like 
to get existing logging converted and then fine tune it.

Thanks,
Bengt

>
> Kind regards,
> Kirk Pepperdine
>
>> On Sep 24, 2015, at 2:11 PM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>
>>
>> Hi Kirk,
>>
>> On 2015-09-24 06:46, Kirk Pepperdine wrote:
>>> Hi all,
>>>
>>> Very nice. There seems to be more concern about breaking existing tooling than need be. As an author of one such tool I am completely unbothered that this JEP will break it. There are currently about 60 flags that affect the output to the GC log. That there are ~60 flags isn’t really an issue. The issue is that about half of those “corrupt” log entries by injecting information in the middle of other entries thus creating a combinatorial number of ways data shows up in the logs. In addition, the same information gets reported in different ways over JDK versions for what seems to be simple author preferences. The remaining flags add data in a fairly benign manner.
>>>
>>> What I believe is far more important is that this JEP lead to logs that maintain the same level of veracity that we have today in a format that isn't destabilized when additional levels of detail are added and remains stable over time.
>> Thanks for looking at the JEP!
>>
>> Yes, providing logging that is not interleaved with other logging is indeed one of the main reasons for moving over to the new logging framework. I agree that this should make things much easier for tools that parse the log files in the future.
>>
>> Thanks,
>> Bengt
>>
>>> Kind regards,
>>> Kirk Pepperdine
>>>




More information about the hotspot-gc-dev mailing list