parallel adaptive gc

[Tony Guan]

Hi Jon,

I am coming clearer about this issue, by implementing this way, we are
only interested in the overall time proportion of each type of
collection, such that minor gc occupies 10% of the time, and major gc
occupies 5% of the time, and thus the mutator utilizes (1-10%-5%)=95%
of the whole execution.

This makes more sense to me now.

Thanks a lot!

Tony

On Thu, Jan 29, 2009 at 1:59 PM, Tony Guan <xguan at cse.unl.edu> wrote:
> 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
>>>
>>>
>>
>>
>