Region-level compaction and related considerations for G1 to better facilitate H-objects

[Tao Mao]

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>
wrote:

> 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
> HeapRegionManager::find_contiguous_empty_or_available().
>

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.
>
> Thanks,
>   Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150707/bd6fc010/attachment.htm>