Eden space is not empty after a Full GC?

[Jon Masamitsu]

Neo Jia wrote:

> On 5/15/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>
>>
>> Response below.
>>
>> Neo Jia wrote:
>>
>> > On 5/14/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>> >
>> >> Yes, it's almost random in terms of which objects get
>> >> left in the young generation.  It is a sliding compaction
>> >> so objects at the higher end of the generation are
>> >> more likely to be left behind.
>> >>
>> >> Leaving objects in the young generation probably
>> >> means that the following collection will also have to
>> >> be a full collection.  It's generally better to have some
>> >> room in the old (mature) generation so that minor
>> >> collections can be done so I would say it would be
>> >> better to have additional space in the old generations.
>> >
>> >
>> > Jon,
>> >
>> > But if all the reserved space for mature space are committed, is there
>> > any way to "borrow" memory from other regions?
>> >
>> >
>>
>> With the UseSerialGC there is not currently a way to get the space from
>> one generation to another.  I meant to say that a user who is in this
>> situation
>> could resize the generations to move more space into the mature (old)
>> generation.  The UseParallelGC collector has an option 
>> UseAdaptiveGCBoundary
>> that does allow the boundary between the young generation and the old
>> generation to move (allowing the borrowing).
>
>
> Jon,
>
> I assume for the ParallelGC the mature space is still using
> generational mark-compact, right? And from the code, I knew that the
> nursery space is still on the lower address of the whole GC-heap,
> which means you can reduce the younger generation by moving the
> boundary upward and reduce the mature space downward. For the younger
> space should be easy because we can easily make the to space and from
> space empty to allow this kind of adjustment. But for the mature
> space, the compaction point (by default) will always be the lower
> address, so how can you adjust the boundary when there are objects
> after compaction?


Yes, ParallelGC does use the mark-compact code but ParallelGC was
changed in jdk5 to have the young generation at the high end of the
address space, then the mature (old) generation and then the
permanent generation.  Also when UseAdaptiveGCBoundary is
used, the young generation grows down and the mature generation
grows up.   From-space and to-space are still above eden.  Since
eden is typically empty after a collection and it is next to the
uncommitted part of the mature generation, we can move the
boundary between the young generation and the old generation.
There is also code to deal with the case where eden is not empty
after a collection. 

>
>> That feature is incomplete in
>> that we have not developed a good policy to decide when the boundary 
>> should
>> be moved and by how much.    The simple policy currently implemented
>> works well sometimes but other times it causes very poor performance.
>
>
> What is the current policy? What kind of applications/benchmarks can
> yield the best or worst performance?


The current policy just moves the boundary after each collection and
gives a larger generation to the collection that is taking more time
(i.e., if the VM is spending more time doing minor collections than
full collections, then the boundary is moved to give more space to
the young generation and visa versa).  When the heap starts to get full
of live data, the boundary is moving constantly (minor collections push
more space into the young generations and full collections push more
space back into the mature generation).  It does not work well for 
applications
that make sudden changes in behavior.  In particular the specjbb2000
and specjbb2005 benchmarks run with increasing work loads.  The
boundary moving  adjusts for the last work load and at some point
cannot adjust optimally for the next larger work load.  I have not
investigated it but I think it is because the mature generation grows
larger than is optimum and then for unknown reasons cannot be
shrunk back.  I mentioned that we can move the boundary even when
eden is empty.  We do that by expanding the mature generation so
that it includes all the live data in  the young generation.   That
might leave just too small a young generation and there is currently
not way to push space back into the young generation when the
mature generation is full.  I cannot think why it would be an advantage
to push live objects from the old generation into the young generation
unless we've moved too many short lived objects into the mature
generation.   Anyway, that's where the policy currently stands.




>
> Thanks,
> Neo
>
>>
>>
>
>