Eden space is not empty after a Full GC?

[Neo Jia]

On 5/15/07, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>
>
> 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.

Jon,

So the permanent generation is on the lower address to make the "ages"
of each generation consistent with its address, right? This will
reduce the overhead of checking inter-generational pointers

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.

It seems that your current adjustment is based on the GC time of each
generation. How
can this connect to the "increasing work loads"? Because I assume that
the increasing work
load should connect with the incoming allocation rate (bytes).

 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.

I assume here you mean the eden space is non-empty, right?

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.

Thank you for your detailed explanation about the current adjustment policy!

Thanks,
Neo

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


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!