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:
>
>> ...
>
>
> 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

Exactly.    We wanted a single test to see if a
reference pointed into the young generation (as opposed to
a test to see if it pointed in from above and another test to see
if it pointed in from below).

>
> 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 should have said fraction of time spent in GC.  So increased work load
means increased allocation rate which means less time between GC's.

>
>  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?


Yes, non-empty.