parallel adaptive gc

Jon Masamitsu Jon.Masamitsu at Sun.COM
Thu Jan 29 18:44:31 UTC 2009


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

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use



More information about the hotspot-gc-dev mailing list