Question regarding G1 option to run parallel Old generation garbage collection?

[Thomas Schatzl]

Hi,

  some more info about the implementation which might clear up other
questions. Did not know where to jump in this discussion because of all
that top-posting.

On Fri, 2012-10-26 at 00:11 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2012-10-25 at 10:53 -0700, Srinivas Ramakrishna wrote:
> 
> > John might be able to tell us whether or how hard G1 tries to reuse
> > Eden/Survivor pages (I had often lobbied for that because AFAIR old G1
> > code did not make any such attempts, but G1 has seen many recent
> > improvements since I last looked).
> 
>   afaik all recently emptied regions (evacuated ones) are first put into
> a list in the order they've been put into the collection set (i.e. the
> regions that were targets for evacuation) and then bulk-added at the
> head of the free region list.

The collection set in G1 seems to consist of regions in that order:

[old gen regions +] new young gen/eden regions [+ survivor regions]

where region types in brackets are optional depending on whether they
are available.

During that process, survivor regions are relabeled as normal young
gen/eden regions. Very briefly looking through the code the reason why
G1 has explicit survivor regions (it does not have from/to spaces!)
seems to be for statistical reasons which may include that some tools
(or the users :) probably expect the collector to have survivor regions.

Imo, from a pure evacuation point of view, for g1 the survivor regions
may be considered just as a fancy label for "the regions that I copied
over the old contents of the eden to if an object does not meet the age
threshold or the amount space I thought would be appropriate for it so
that I avoid copying over too many objects and maybe ten other
conditions". It's just so much shorter ;)

@Kirk: this is very similar to what you described about the IBM
collector.

> 
> I.e. to where the next region allocations will occur from. So you will
> automatically get the desired effect to some extent.

Note that any of the regions in the collection set have just been
touched, except in the probably unusual case that it has been completely
empty. Maybe a preference of just recently allocated/used regions would
in case of tight space improve the situation a little. I.e. it is
possible that by choosing the wrong regions the gc could cause paging of
other young gen regions that in turn are needed later (paged in +
kicking out others all the time). Maybe someone else tried to evaluate
that already?

Then again, is a configuration that does not even have enough space to
keep the young gen in memory a realistic one?

(Just thinking loud).

Thomas