Bug in G1GC it performs Full GC when code cache is full resulting in overkill

[Thomas Schatzl]

Hi,

On Mon, 2013-06-03 at 14:23 +0300, Martin Makundi wrote:
> Hi!
> 
> > > We seem to be suffering from humongous and something else too... I
> > > will attempt to investigate how the cause can be captured to see if
> > > they can be made smaller.
> > >
> > > Why does it need to do a stop the world instead of just making space
> > > for the items that need to be placed?
> >
> > There is no reason for the current behavior other than that trying to
> > make space using a targeted mixed collection in this case is just not
> > implemented in G1.
> 
> So could we improve it by adding that 

Yes, patches are welcome :)

I think a patch needs approximately the following changes:

- instead of issuing a full gc vm operation in that case, issue a
special mixed gc.

- in this mixed gc first scan the region table to find the place (area)
where the least amount of regions need to be evacuated, ie. least total
amount of cost.
(If you want to optimize for performance of these mixed gcs, there may
be other goals worth pursuing. A first prototype might just take the
first N regions).

Since g1 keeps remembered sets for all regions anyway, i.e. can evacuate
everything at any time, there is no other limitation here I can think
of.

Put the regions into the list of evacuation candidates at the top, and
tell g1 that it absolutely should evacuate these number of regions.

- sort of pre-reserve already free regions in that area so that the
mixed gc does not allocate into them during evacuation :)

- do the mixed gc as usual

- allocate the large object in that now free place.

All functionality is there, things just need to be wired together
differently.

> and also allowing varying-size
> regions, to allow smaller and larger (even bigger than 32m) objects?

"Humonguous regions" already enable the use of arbitrarily sized
objects.

I am not sure what overall advantage arbitrarily sized regions would
have; while they might solve this particular problem better (in which
way?) they would require massive changes in the collector/VM to support
them. Also, this would likely have a large impact on achievable
performance. E.g. evenly sized power-of-two regions give a lot of
opportunities for optimizations in many places.

There are other options, like cutting large objects into multiple
smaller arrays (arraylets etc), but they require compiler support.

Hth,
Thomas