<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>I’ve got this from a 1.8.0_20 log but it’s been around for some time.</div><div><br></div><div><div style="font-size: 13px;">[Eden: 448.0M(448.0M)->0.0B(448.0M) Survivors: 64.0M->64.0M Heap: 7740.7M(15.0G)->7334.2M(15.0G)]</div><div style="font-size: 13px;">15116.779: [GC cleanup 7334M->6817M(15G), 0.0181473 secs]</div></div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">As you can see the occupancy before collection is reported as 7334M where as the occupancy after collection in the summary record is 7334.2M.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">In this case the collections are less than 5ms apart which means that the .2M discrepancy would appear to be a rounding error due to the precision of how values are being reported. I briefly looked JDK code and it seems as if EXT_SIZE_FORMAT<span class="Apple-tab-span" style="white-space:pre"> </span> is being used in the initial summary but construction/printing the GC cleanup seems to be delegated to VMThread and it’s not using the same format.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">On a side note, simply reporting in bytes would be a nice step in simplifying things.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">Kind regards,</div><div style="font-size: 13px;">Kirk Pepperdine</div><div style="font-size: 13px;"><br></div></body></html>