parallel adaptive gc

[Tony Guan]

Hi Jon,

Thank you for the information.
I am OK with the for the cost part, but just don't understand the
time-interval part.
the time-interval should be (last mutator time)+(gc pause)
but in the implementation, it turns to be (last this type gc ends to
this time this type gc starts) which may include 1 or more mutator
times and 1 or more other type gc pause.

is this valid?


On Thu, Jan 29, 2009 at 12:44 PM, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
> Tony,
>
> The definition of GC cost used in the adaptive size policy
> work is the fraction
>
>      GC-pause-time  /  time-interval
>
> where time-interval is the time from the start of
> of one GC to the start of the next GC.  The time-interval
> is calculated as
>
>    time-interval = GC-pause-time + time-between-GC
>
> where time-between-GC is time from the end of a GC
> to the start of the next GC.
>
> Each GC cost is calculated separately (minor GC cost
> and major GC cost).  The intent is that the
> time-between-GC includes all the times (mutator
> times and times for other types of GC's).
>
> Does that make sense?
>
> I can't say why the GC cost is modeled as this fraction.
> Before the current adaptive size policy there was
> an implementation in 1.4.2 that did the sizing of the
> generations and the GC cost model may have come
> from that previous implementation.
>
> Jon
>
> Tony Guan wrote On 01/29/09 09:25,:
>
>>Hi,
>>I just reviewed some of the code of the class PSAdaptiveSizePolicy.
>>There is one thing I don't understand, why the mutator cost is
>>caculated 2 times: one is measured from the end of the minor
>>collection till the beginning of the next minor collection:
>>(_latest_minor_mutator_interval_seconds=_minor_timer.seconds), and the
>>other is measured from the end of a major collection till the
>>beginning of the next major collection.(
>>_latest_major_mutator_interval_seconds = _major_timer.seconds())
>>
>>And the cost of minor collection is calculated as (this minor gc
>>time)/(this minor gc time+last MINOR mutator time)
>>the cost of major collection is :  (this major gc time)/(this major gc
>>time+last MAJOR mutator time)
>>
>>But in fact, the two mutator time can be overlapping, since we don't
>>stop minor timer even when we are doing the major timer, and vice
>>versa.
>>So we end up with such possible counting:
>>time1                              time2
>>time3
>>minor gc stops               minor gc starts            minor gc stops
>>minor_mutator_starts     minor_mutator_ends    minor_mutator_starts
>>
>>time4                              time5                            time6
>>major gc starts                major gc stops             minor gc starts
>>major mutator ends         major mutator starts     minor mutator ends
>>
>>time 7
>>minor gc ends
>>minor mutator starts.
>>
>>If we are at time 7, and want to caculate minor gc cost, then
>>last_minor_mutator is (time6-time3), and minor gc time is
>>(time7-time6)
>>but here (time6-time3)=
>>(time4-time3)+(time5-time4)+(time6-time5)=mutator time + full gc
>>time+mutator time.
>>
>>based on such cost calculation, I really doubt whether we could be
>>precise enough to do any prediction?
>>
>>Or that's maybe just my incomplete understanding of it, can somebody
>>help me out?
>>
>>Thanks!
>>
>>
>>Tony
>>_______________________________________________
>>hotspot-gc-use mailing list
>>hotspot-gc-use at openjdk.java.net
>>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>
>