Region-level compaction and related considerations for G1 to better facilitate H-objects
yiyeguhu at gmail.com
Tue Jul 7 21:14:53 UTC 2015
Thank you for reply, Thomas! Please see inline. It looks there are at least
two ideas that can be good suggestions here.
On Mon, Jun 29, 2015 at 5:29 AM, Thomas Schatzl <thomas.schatzl at oracle.com>
> Hi Tao,
> On Fri, 2015-06-26 at 17:46 -0700, Tao Mao wrote:
> > Hi there,
> > Recently in using G1 on our realtime-focused production servers, I
> > noticed some full GCs were triggered by humongous allocation failure
> > due to fragmentation of free regions while it's still having enough
> > space in number.
> > I'm not suggesting that we move H-objects around. Just wonder if we
> > have the following or similar in place or plan to have. e.g.,
> In such cases, moving around (small) humongous objects might actually be
> a good idea (compared to a full gc).
> > (1) For evacuation, we grab free regions closer to the start of heap
> > and/or try to grab free regions with fewer neighboring free regions.
> 1a) has been implemented in some 8u release, either u20 or u40. If I
> remember correctly, new old gen regions (that includes humongous) are
> allocated from the end of the heap downwards, new young regions from the
> start of the heap.
I saw that piece of code. Nice to have.
> The second option has not been explored (try to grab free regions
> according to other policies), but seems straightforward (but some work)
> to do. Check out G1CollectedHeap::new_region().
Might not be that significant if the above is there. The above mechanism
realizes that in the end, IMO.
> Controlling the destination regions only solves half of the problem
> though, but a useful mechanism also requires control of the source
> regions: in a given evacuation there are often a lot of almost equally
> expensive regions to collect, so any change according to e.g. "try to
> create as much as possible contiguous free areas" might help a lot
> without a lot of performance impact.
Good idea! You may want to record this idea somewhere.
> > (2) Humongous object allocation tries to find the most suitable
> > location, i.e., least waste of its neighboring free regions after
> > H-allocation.
> Check out G1CollectedHeap::humongous_obj_allocate(). The entry point
> that might be most interesting would be to change
I checked the latest code. It looks like the second point (finding the most
suitable contiguous regions for humongous allocation) would be
straightforward to implement in HeapRegionManager::find_contiguous().
> > Is there something along this line to fight region-level
> > fragmentation, or related fixed bugs? If so, any pointers?
> Above mentioned is what I know in that area.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev