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

[Bengt Rutisson]

Hi Kirk,

On 2016-02-01 16:30, kirk.pepperdine at gmail.com wrote:
> Hi Bengt,
>
>> 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
> Thank you for making this public.
>> 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.
> So my understanding of the thread suggests that this decision is based on a very specialized condition created by this benchmark that wastes a lot of memory. Again, it is my opinion that occupancy are important and that relying on an estimate based on region size is simply far too course a measure for 1M regions and only gets worse as region size increases. That’s not accounting for the inaccuracy due to waste. I have a number of experimental analytics that will tolerate a fair amount of “noise” in the data when using K granularity. Using M granularity is and issue that this gives us even worse precision than that.

The estimation you get by multiplying with the region size is exactly as 
good or as bad as it was before when that multiplication was done in the 
code. So, I don't really understand your accuracy argument.

> If this is simply a matter of time, as I’ve mentioned before, I’m quite happy to pitch to help get it right.

It is not a matter of implementation time. It is a matter of execution 
time. To get the exact number you need to do a more expensive operation 
in the code. The implementation is already in place in the patch I 
propose. This gives you the exact numbers. But it is only available at 
trace level. I think you can get by in most cases with the estimate that 
multiplying with the region size gives you. This was all that was 
present before, so I think it should work for most cases. If you really 
need to dig in to the details of what is going on you can enable trace 
logging and get the exact numbers.

Bengt

>
> Kind regards,
> Kirk
>