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

[Bengt Rutisson]

Tony,

On 8/29/13 4:12 PM, Tony Printezis wrote:
> Bengt,
>
> Doesn't what I said also applies for users who do not set -Xms? So, if 
> -Xms is by default 6m, a user launches the VM with:
>
> java -Xmx32G ...
>
> and the region size is calculated to be 8m, what's the initial heap 
> size (8m, i.e. one region)?

No, by default we calculate a reasonable -Xms. So as long as the policy 
uses that value and not the min heap size I think we are fine.

Bengt

>
> Tony
>
> On 8/29/13 10:08 AM, Bengt Rutisson wrote:
>>
>> 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
>>>
>>
>