rounding error in logs

[Kirk Pepperdine]

Hi Thomas,

Indeed… strange but I can see it this morning... but it’s not possible for me to comment on it. 

Ok, I agree, not a fantastically high priority item but that would be my comment if I were able to comment.

The problem of the subtle rounding error is due to the fact that log records, instead of sharing common formats, define their own. So while one set of records share EXT_SIZE_FORMAT (g1CollectorPolicy.cpp:#define EXT_SIZE_FORMAT “%.1f%s” other records use a completely separate integer definition. In my experience most people use either Censum or one of the OSS tools or a home grown tool to look at these logs which implies that human readability is less important. And if humans want values to be rounded a flag like -XX:PrintMemoryRounding=[G,M,K,B] could be introduced. I’m not a fan of G1LogLevel=finest as this turns on bags of stuff that may or may not be relevant to the problem at hand and increases the complexity of parsing the log files. This is especially true in light of the corruption that often occurs in both CMS and G1 logs that can be difficult to untangle.


Format isn’t typically that much of a problem for the home grown folks as they only deal with 1 log format, theirs. If it changes when they change JVM they can simply change their parser. However this is very painful for the few of us that actually try to maintain tools that work across all versions and support a variety of flag collector and flag combinations. As you can probably imagine, that this rounding error exists means that it needs to be compensated for in the tooling for as long as these versions of the JVM are in play again.

Kind regards,
Kirk Pepperdine

 
On Sep 12, 2014, at 9:23 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:

> Hi,
> 
> On Fri, 2014-09-12 at 00:12 +0200, Kirk Pepperdine wrote:
>> Hi Thomas,
>> 
>> Thanks for this. I don’t see CR JDK-8058221 showing up so it’s difficult to comment. What you’ve mentioned is ok but I think it would be nice is the logs used the same formatting string.
>> 
>> BTW, my comment on reporting in bytes still stands.. it would eliminate the need for any formatting! Just print longs ;-)
>> 
> 
> the bug is publicly available so I do not know why it is not accessible
> for you.
> 
> Here's the description:
> 
> "In the gc, heap sizes are typically rounded to some (rather abritrary)
> k/M/G values for better human consumption. 
> 
> This introduces subtle rounding problems when calculating values from it
> (like number of promoted bytes being negative for no reason) 
> 
> Add an option to allow the size format output to always be written in
> bytes. 
> 
> This feature may also be automatically enabled by other options like
> G1LogLevel=finest. "
> 
> Thanks,
>  Thomas
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140912/e880f75e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140912/e880f75e/signature.asc>