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 06:03:22 PDT 2013


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).

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.

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