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

[Srinivas Ramakrishna]

Thomas, while adding newly freed regions to the head of a common global
free region list
probably achieves much reuse, I was suggesting something even stronger and
deliberate, in that a much smaller set of
regions be preferred for repeated reuse for Eden allocation and for reuse
as survivor regions, kind of
segregating that smaller subset completely from regions used for tenuring
objects. On the other
hand, that view of object access frequencies is likely much too simplistic,
conflating object age
with (the inverse of) short-term access frequency. Anyway, with G1+NUMA, I
am sure some of
these region allocation policies will get somewhat tweaked and revised.

-- ramki


On Thu, Oct 25, 2012 at 3:48 PM, Thomas Schatzl <thomas.schatzl at jku.at>wrote:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121025/8f4c50af/attachment.htm>