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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
