Young Generation Heap Layout

[Thomas Schatzl]

Hi,

On Fri, 2013-11-29 at 10:30 +0000, Blair Archibald wrote:
> Hi,
> 
> Thanks for all your help so far!
> 
> So my idea was that we aren't scaling the boundary between old and young,
> (or eden and survivor as adaptive size seems to already do) but instead we
> would have the heap as follows:
> 
> Old | S0 | S1 | Eden |
> 
> where S0 starts at the low of the virtual space shown in:
> http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.generations
> 
> Since Perm has been moved, we should be able to use the
> PSVirtualSpace::expand_by method (called by resize generations) to ask the
> OS for some extra virtual space at the end of the young gen i.e
> 
> S0 | S1 | Eden | New Virtual Space

As an alternative you could keep the current layout and add code that
updates the virtual space members.

Note that I am almost sure that some (C++) code contains copies of the
virtual space values (base address/size, the size policies and the
collector policies) and you have to update them. But this is the same
problem than when you expand at high addresses.

At least you do not need to dig into code generation when changing this
in this way.

> Then we can scale into this new space. (eventually we scale it back down!)
> 
> However as mentioned before I can't seem to place the young gen with Eden
> anywhere except virtual_space()->low() without a large amount of errors
> occurring (generally segfaults) and I'm wondering mainly why this would be
> the case?

Generated (barrier) code assumes that the young generation is located
before the old gen to distinguish between references from/to the
old/young generation. You need to fix code generation.

Thomas