Young Generation Heap Layout

[Peter B. Kessler]

I don't know of a reason that you couldn't reorder the spaces within the young generation.  They are arranged that way for a reason similar to the one you are thinking of, but with respect to the heap as a whole.  Long ago the heap used to be

     Eden | From | To | Old

probably because that's the obvious way to do it and no one thought there were advantages to be had from different layouts.  But then we wanted to resize the old generation, and the observation was that after a young generation collection the eden is almost always empty (always in some collectors), and after a compacting collection of the old generation the high end of the old generation is empty, so if we laid the heap out

     Old | Eden | From | To

then we could move the boundary between Old and Eden.

Are you thinking of doing something similar between from (empty after collections) and eden?  Then you could move that boundary every other young generation collection.  That is, when From is adjacent to Eden.  But that happens even with the spaces laid out as they are, with To just above Eden.  Now I'm curious as to what you are thinking about.

It's convenient (read, performant) to have a single address comparison to tell you whether an oop is in the young generation or the old generation, and within the young generation whether it is in Eden or one of the survivor spaces.  It doesn't seem like you'd make those less efficient.

			... peter

On 2013/11/28 14:02, Blair Archibald wrote:
> Hi,
>
> I'm experimenting with new methods of performing heap resizing (like
> Ergonomics/Adaptive size policy but with different principles/techniques).
>
> I'm working mainly with the ParallelScavenge GC/Heap and was wondering if
> there is a particular reason that the young generation needs to be in the
> form:
>
> Eden | To | From
>
> I would like to do some (fairly aggressive) Eden resizing so it would be
> beneficial to have a young generation as follows:
>
> To | From | Eden
>
> This provides the possibility of scaling the generation to provide free
> space at the end of eden. When I tried this however I got various issues
> with CompressedOOPs and when running without CompressedOOPs I get strange
> segfaults.
>
> Are there any particular areas where this space layout invariant needs to
> be enforced? Would it ever be possible to have a layout with eden at the
> end?
>
> Many thanks,
> Blair
>