RFR(S): 7189971: Implement CMSWaitDuration for non-incremental mode of CMS

Michal Frajt michal at frajt.eu
Thu Jan 17 11:00:14 UTC 2013


 
Hi Bernd,

The catching up with the filling old gen is handled via the _full_gc_requested state (set and notify on the CGC_lock). The RMI GC interval is probably not handled.

The current CMS wait duration implementation is having endless wait limit implemented very same way. There is no code protection to help with situations where the wakeup (notify) is missing. The new imlementation does not make anything worse or better in the endless wait for the scavenge. 

The endless (forever) wait support was implemented on ramki's request. Please find here http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-December/005394.html his detailed implementation proposal. 

Regards,
Michal

 
Od: hotspot-gc-dev-bounces at openjdk.java.net
Komu: hotspot-gc-dev at openjdk.java.net
Kopie: 
Datum: Thu, 10 Jan 2013 22:02:05 +0100
Předmet: Re: RFR(S): 7189971: Implement CMSWaitDuration for non-incremental mode of CMS


> Hello,
> 
> two amateur :) questions:
> 
> Am 10.01.2013, 21:20 Uhr, schrieb John Cuthbertson
> :
> >> I've done a couple of sanity tests with GCOld with CMSWaitDuration=0 
> >> and CMSWaitDuration=1500 with CMS.
> 
> Is there a risk involved in waiting long/endless? For example larger than
> some RMI GC intervall or too long for catching up with the filling of OG?
> How to test for that?
> 
> >>>> // No wait limit, wait if necessary forever
> >>>> wait_time_millis = 0;
> 
> I typically not use a endless wait limit when there is a loop with a fixed
> endtime but use a large but limited number. This helps to catch situations
> where wakeup is missing (for example on shutdown) or lost. Would it be an
> option to use something like 10s?
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net




More information about the hotspot-gc-dev mailing list