Re: “abort preclean due to time” in Concurrent Mark & Sweep

[Chi Ho Kwok]

It's still a basic GC tuning problem, it has nothing to do with abortable
preclean etc.

1. Post the full command line with all the options.
2. Use jvisualvm to monitor the heap. It's in the SDK\bin folder.
3. Make sure the average heap usage is 10% lower than
CMSInitiatingOccupancyFraction.
4. If CMS is still running all the time, learn to set a proper young
generation size.
5. And read http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

On Tue, May 3, 2011 at 3:02 PM, Li Li <fancyerii at gmail.com> wrote:

> I forgot to say, the free heap size is larger than 30%
>
> 2011/5/3 Chi Ho Kwok <chkwok at digibites.nl>:
> > You're looking at the wrong thing. Your heap usage is above Heap size x
> > CMSInitiatingOccupancyFraction%, causing GC to be run continuously. Make
> > that percentage higher or increase the heap size.
> > See -XX:CMSInitiatingOccupancyFraction and -Xmx
> > On Tue, May 3, 2011 at 12:31 PM, Li Li <fancyerii at gmail.com> wrote:
> >>
> >> hi all
> >>    I confronted a strange case. The hotspot jvm was always doing gc
> >> and consumed many cpu resources(from 50% to 300% cpu usage). And when
> >> I turned on gc information. I
> >> found "abort preclean due to time" in the gc logs.
> >>    So I googled and found some similar questions in
> >>
> >>
> http://stackoverflow.com/questions/1834501/abort-preclean-due-to-time-in-concurrent-mark-sweep
> >> and
> >>
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-October/000482.html
> .
> >> And http://blogs.sun.com/jonthecollector/entry/did_you_know is
> >> suggested to read.
> >>    I read the blog post and can't understand well.
> >>    As it says, CMS full gc has follwoing phases:
> >>        STW initial mark
> >>        Concurrent marking
> >>        Concurrent precleaning
> >>        STW remark
> >>        Concurrent sweeping
> >>        Concurrent reset
> >>
> >>    "Ok, so here's the punch line for all this. When we're doing the
> >> precleaning we do the sampling of the young generation top for a fixed
> >> amount of time before starting the remark. That fixed amount of time
> >> is CMSMaxAbortablePrecleanTime and its default value is 5 seconds. The
> >> best situation is to have a minor collection happen during the
> >> sampling. When that happens the sampling is done over the entire
> >> region in the young generation from its start to its final top. If a
> >> minor collection is not done during that 5 seconds then the region
> >> below the first sample is 1 chunk and it might be the majority of the
> >> young generation. Such a chunking doesn't spread the work out evenly
> >> to the GC threads so reduces the effective parallelism. " --quoted
> >> from this post.
> >>
> >>    In my option, Concurrent precleaning is the preparing stage for
> >> remark. It will split the young generation to chunks so remark can do
> >> it parallelly. It expected a young gc in order
> >> to split chunks evenly. If there is no young gc before time
> >> out(CMSMaxAbortablePrecleanTime ), it seems it this gc will fail and
> >> all following phases will be skipped.
> >>
> >>    So when the system load is light(which means there will be no
> >> minor gc), precleaning  will always  time out and full gc will always
> >> fail. cpu is waste.
> >>
> >>   Some suggested enlarge CMSMaxAbortablePrecleanTime. Maybe it can
> >> solve this problem. But CMS collector,not like other collectors that
> >> will perform gc when full. it will
> >> perform gc when space usage is larger than 92%(68% for older version
> >> of hotspot) or jvm feel it should do it. if this value is too large,
> >> it will stop the world longer.
> >>
> >>     "Based on recent history, the concurrent collector maintains
> >> estimates of the time remaining before the tenured generation will be
> >> exhausted and of the time needed for a concurrent collection cycle.
> >> Based on these dynamic estimates, a concurrent collection cycle will
> >> be started with the aim of completing the collection cycle before the
> >> tenured generation is exhausted. These estimates are padded for
> >> safety, since the concurrent mode failure can be very costly.
> >>
> >>      A concurrent collection will also start if the occupancy of the
> >> tenured generation exceeds an initiating occupancy, a percentage of
> >> the tenured generation. The default value of this initiating occupancy
> >> threshold is approximately 92%, but the value is subject to change
> >> from release to release. "
> >>    --quoted from
> >>
> http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#cms
> >>
> >>
> >>    Another solution: "There is an option CMSScavengeBeforeRemark
> >> which is off by default. If turned on, it will cause a minor
> >> collection to occur just before the remark. That's good because it
> >> will reduce the remark pause. That's bad because there is a minor
> >> collection pause followed immediately by the remark pause which looks
> >> like 1 big fat pause.l "
> >>
> >>     My question is that why the collector so stupid that it don't do
> >> it  like this. If the system is busy, it works like before. Because
> >> it's busy, minor gc will occur and precleaning will success in the
> >> future. If the system is idling, it can adjust the
> >> CMSMaxAbortablePrecleanTime or turning CMSScavengeBeforeRemark  on.
> >> _______________________________________________
> >> hotspot-gc-use mailing list
> >> hotspot-gc-use at openjdk.java.net
> >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20110503/a5622a7d/attachment-0001.html