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

[Thomas Schatzl]

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.

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

I do not remember that this has changed recently.

John may know better about this though.

> need to keep the "To" survivor space in reserve separately, but draw
> from a common pool of free regions. In practice, it might be sensible
> to reuse recently collected Eden regions (can't recall how hard G1
> tries to do that) because it's possible that some caches are warm, but
> with today's huge young generation sizes, may be it doesn't make sense
> to talk about cache reuse. 

Not sure what caching of these regions helps here: I'd naively assume
that you actually don't really want the contents of these regions in the
cache because they were just made obsolete by evacuation. Maybe memory
metadata, e.g. TLB entries?
Note that young gen is often very large too (10+GB?) and the regions too
in that case (16M in such heaps), so I'm not sure there is much to gain
by more clever management or e.g. if you prefetched/pretouched them.
So I'd tend to agree to your analysis without measurements.

Hth,
Thomas