RFR (S): 8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size
Tony Printezis
tprintezis at twitter.com
Thu Aug 29 14:12:30 UTC 2013
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)?
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
>>
>
--
Tony Printezis | Staff Software Engineer | Twitter
@TonyPrintezis
tprintezis at twitter.com
More information about the hotspot-gc-dev
mailing list