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

[Li Li]

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