RFR (S): 8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size

[Bengt Rutisson]

Hi Tony,

Thanks for looking at this!

Comments inline.

On 8/29/13 3:03 PM, Tony Printezis wrote:
> Hi Bengt,
>
> Yeah, I struggled with this heuristic when I did the original 
> implementation of the heap region calculation. The issue only arises 
> when the gap between the min and max heap size is very large. So, if 
> someone launches the VM with:
>
> java -Xms32m -Xmx64g ...
>
> and G1 picks a region size of 8m, it'd start with only 4 regions which 
> will probably make performance right at the beginning will be terrible 
> (but I agree that it will be better as the heap grows, compared to if 
> an 1m region size was used).

Agreed. And just to be clear. The main problem with the existing policy 
is that it by default always picks 1m regions if nothing is set on the 
command line. This is due to the fact that it is not based on the 
initial heap size (-Xms) but on the min heap size, which by default is 
in the order of 6m. So, those who set -Xms on the command line have 
experienced less of a problem. At least if they set -Xms to high enough 
values.

>
> Can I suggest maybe an additional policy change? Use the avg to 
> calculate the region size, as you proposed, but potentially adjust the 
> min heap size based on a min region number (let's pick a number of a 
> hat: 16; you might want to revise this). So, in the above example:
>
> -Xms32m -Xmx64g -> region size = 8m
>
> you'll actually adjust the min heap size 16 x 8m = 128m. This will 
> avoid the potentially bad behavior right at the start. Of course, 
> you'll start with a larger heap size than what the user asked for. On 
> the other hand, if someone uses a huge max they probably expect the 
> heap to grow. So starting with a large min might be OK.

I see your point, but I don't really like the fact that if someone 
explicitly sets -Xms on the command line we would ignore that and use a 
value that is four times as large. Also, there is the possibility to set 
the region size using G1HeapRegionSize on the command line. So, in this 
use case I kind of think it would be better to leave it up to the user 
to indicate if the heap is more likely to be 32m or 64g by setting the 
region size explicitly.

Thanks,
Bengt

>
> Tony
>
> On 8/29/13 5:26 AM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this change:
>>
>> http://cr.openjdk.java.net/~brutisso/8019902/webrev.00/
>>
>> The fact that G1 by default bases its region size on the minimum heap 
>> size means that out of the box the region size will always be 1M. 
>> This is a problem on large machines with lots of memory. We pick a 
>> large heap size but get a very small region size. The small regions 
>> are inefficient and cause a lot of memory footprint. Normally we aim 
>> to get around 2048 regions, but on a machine with a lot of memory we 
>> might pick a default max heap size of 32G, which means that we will 
>> get ~32000 regions. This can lead to out of memory situations - 
>> especially on Solaris x86.
>>
>> This patch changes the heuristics for picking the region size to use 
>> the average between initial heap size (-Xms) and the maximum heap 
>> size (-Xmx). This means that for large heaps we will pick larger 
>> region sizes. In the 32G example we will now pick a region size of 8m 
>> which means that we will have 4000 regions which is more reasonable.
>>
>> Thanks,
>> Bengt
>