RFR: JDK-8148736: Let the G1 heap transition log regions instead of bytes

[Bengt Rutisson]

On 2016-02-01 14:13, kirk.pepperdine at gmail.com wrote:
> Hi Bengt,
>
>>>
>>> Sorry but I hit the send too quickly. The occupancy numbers before and after the collection are the numbers that I’m not so happy losing. It is true that they never did add up but it was never more than what would be normal rounding error given that things are reported in K and M and not bytes. Even with the small errors, the numbers are incredibly useful.
>>
>> If  you multiply the region numbers that are now logged with the region size you get the same occupancy numbers as before. It is hard to say if the difference is small or not. It depends on the fragmentation and the region size. In Jenny's example for JDK-8147976 the difference was > 1G for a 50G heap. I find that too much of a difference to make the numbers feel reliable. The proposed change makes it clearer what is going on and why the difference is there.
> Sorry to be repetitive here but I can’t get pass being feeling that this move represents a loss of information. If there is an inaccuracy in the measures I would be more comfortable finding out why the values are inaccurate rather than throwing the baby out with the bath water.

We know the reason for the inaccurate measurements. I had some pretty 
detailed descriptions of it in JDK-8147976, but I now realize that I 
didn't make them publicly viewable since I was using an internal 
benchmark for the investigation. However, I don't think there is 
anything that can't be public about it, so I changed the comments to be 
visible. Please take a new look at the bug report for a detailed 
descriptions of the problem.

https://bugs.openjdk.java.net/browse/JDK-8147976

Basically the conclusion is that there is no fast way to get the correct 
numbers. There is a way to get the exact numbers, but that involves 
iterating over all heap regions, which can potentially take some time. 
My proposed patch adds the exact logging at trace level. This makes it 
possible to use that if you are tracking down a particular problem but 
you can use the fast logging to get a rough number in normal execution.

Regards,
Bengt

>
> Kind regards,
> Kirk
>