Code Review Request: 6819085 G1: use larger and/or user settable region size

[Vikram A]

hi Tony,

missed that part of bounding the region size. thanks.

rgds,
Vikram

On Fri, Jul 31, 2009 at 9:34 PM, Tony
Printezis<Antonios.Printezis at sun.com> wrote:
> Vikram,
>
> Hi. With testing we have done so far with 1G-4G heaps, 1m region size seemed
> to work well. However, We have been recently experimenting with 24g-32g
> heaps and for that we've seen that larger region sizes are beneficial (in
> order to cut down the number of regions). Which is one of the reasons why I
> worked on this CR. Also note that, after the region size calculation you
> showed, I do bound the region size by MIN_REGION_SIZE and MAX_REGION_SIZE.
> So, the minimum region size, currently, will be 1m and in some cases ,we
> might use a larger one (up to currently 32m).
>
> Tony
>
> Vikram A wrote:
>>
>> hi Tony,
>>
>> Just thinking out loud here.
>>
>> You had once outlined  that we get most benefit with 1MB regions based
>> on your testing.
>>
>>  in arguments.cpp
>>
>> +   uintx region_size = G1HeapRegionSize;
>> +   if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {
>> +     // We base the automatic calculation on the min heap size. This
>> +     // can be problematic if the spread between min and max is quite
>> +     // wide, imagine -Xms128m -Xmx32g. But, if we decided it based on
>> +     // the max size, the region size might be way too small for the
>> +     // min size. Either way, some users might have to set the region
>> +     // size manually for some -Xms / -Xmx combos.
>> +     region_size = min_heap_size() / TARGET_REGION_NUMBER;
>> +   }
>>
>> with this for many small application it seems to me that the region
>> size is disturbed.
>>
>> eg. in the above doc. you mention
>> -Xms128, consider the heap to be  and TARGET_REGION_NUMBER is defined as
>> 2048.
>> So, total heap will be
>> 128 * 1024(K) = 131072K
>> now dividing 131072K/2048 = 64K for each region.
>>
>> If this inpterpretation is right and there is a reason for doing it
>> this way, aren't we losing the adv we gained with 1024K region.
>> this seems like a very small region size and would induce frequent GC,
>> although could be with small pause time.
>>
>> I would assume that many enterprise would run their java with larger
>> heaps than this, but considering this is also for every one, should
>> the 1024K region size be useful to keep by default while allowing this
>> fix to modify it for advanced user.
>>
>> Like I said just my thoughts.
>>
>> regards,
>> Vikram.
>>
>> On Fri, Jul 31, 2009 at 2:51 AM, Tony Printezis
>> <Antonios.Printezis at sun.com> wrote:
>>
>>>
>>> http://cr.openjdk.java.net/~tonyp/6819085/webrev.0/
>>>
>>> The idea is to allow the user to set the region size with a parameter
>>> (-XX:G1HeapRegionSize=N).
>>>
>>> Tony
>>>
>>> --
>>> ----------------------------------------------------------------------
>>> | Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
>>> |                                   | MS BUR02-311                   |
>>> | e-mail: tony.printezis at sun.com    | 35 Network Drive               |
>>> | office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
>>> ----------------------------------------------------------------------
>>> e-mail client: Thunderbird (Solaris)
>>>
>>>
>>>
>
> --
> ---------------------------------------------------------------------
> | Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
> |                                  | MS UBUR02-311                  |
> | e-mail: tony.printezis at sun.com   | 35 Network Drive               |
> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
> ---------------------------------------------------------------------
> e-mail client: Thunderbird (Linux)
>
>
>