Deciding between 2MB or 32MB region size in G1

[yu.zhang at oracle.com]

Hi, Amit,

IMO, there is no one size fits all.

Some considerations about the bigger region size:

Reduce the humongous objects. The humongous objects are allocated in old 
gen. If they can not be collected during young gc, they can fill up the 
old gen quickly without marking or full gc.

Less remember set to keep track of.

Bigger TLAB. This could be good or bad. With bigger tlab, threads need 
less refill trip, but may waste more tlab space. It depends on the 
objects size.

Possible bigger waste due to humongous objects (depends on the size of 
the objects)

Possible end of region waste for allocation.

Maybe others have more comments.

Thanks

Jenny


On 02/01/2017 05:54 AM, Amit Balode wrote:
> Hello, We have multiple applications running in production where 
> predicting size of the runtime object is kinda tough and random. It 
> could vary from 1KB to 25MB for different applications. To not have 
> too many lingering configs for different applications, I am trying to 
> come up with standard set of configs which could be applicable to all 
> applications. Some applications do not exceed 10KB object size, so I 
> could definitely keep 2MB as region size for them. But I am wondering 
> what would be disadvantage of setting all applications to 32MB region 
> size regardless of how small the object is?
>
> Is it that fragmentation issues will happen more if you have less 
> regions? If so, will the fragmentation issue happen only during 
> humongous allocations?
> In term of performance, will selection of size change anything?
>
> -- 
> Thanks & Regards,
> Amit.Balode
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20170202/ac2b913f/attachment-0001.html>