two trivial bug about UseGCLogFileRotation and CMSDumpAtPromotionFailure ?

[Yumin Qi]

For first one:

The rotation has file size limit so the file will never be bigger than
the limit. It used 'rewind' to reset the file pointer to start, this
will clear the end of file indicator too. Maybe this is the reason the
size showed is not correct? The time stamp in the file indicates the end
of log.

Thanks
Yumin



On 12/20/2012 12:57 AM, 谢良 wrote:
> Vm option :
> -Xmx49152m -Xms49152m -Xmn1024m -Xss256k -XX:MaxDirectMemorySize=1024m
> -XX:+UseConcMarkSweepGC -XX:+CMSDumpAtPromotionFailure
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=100
> -XX:GCLogFileSize=128m
> -Xloggc:/home/work/log/hbase/ggsrv-miliao/regionserver/regionserver_gc.log
> ...
>
> $java -version
> java version "1.6.0_37"
> Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
>
> After a promotion failure, there's an expected dump, but there're two
> more things catch my eye :
> 1) the dumped gc log size was not limited by GCLogFileSize parameter
>
> -rw-rw-r-- 1 work work 2.7K Dec 20 12:12 regionserver_gc.log.2
> -rw-rw-r-- 1 work work 11499056168 Dec 20 12:12 regionserver_gc.log.1
> -rw-rw-r-- 1 work work 77K Dec 20 16:21 regionserver_gc.log.0
>
> Looked into current codebase, seems the gc log rolling is triggered in
> SafepointSynchronize::do_cleanup_tasks() only, if we have huge dump
> info be written during a vm operation, the GCLogFileSize limit is
> breakable
>
> 2) Another weird problem is the PrintSafepointStatistics output :
>
> vmop [threads: total initially_running wait_to_block] [time: spin
> block sync cleanup vmop] page_trap_count
> 158282.484: GenCollectForAllocation [ 325 0 0 ] [ 0 0 0 2 113 ] 0
> vmop [threads: total initially_running wait_to_block] [time: spin
> block sync cleanup vmop] page_trap_count
> 158283.141: GenCollectForAllocation [ 325 1 2 ] [ 0 0 0 2 112 ] 0
> vmop [threads: total initially_running wait_to_block] [time: spin
> block sync cleanup vmop] page_trap_count
> 158283.766: GenCollectForAllocation [ 325 0 0 ] [ 0 0 0 2543271 ] 0
>
> I could see 4 fields only at the last line, not 5, i'm a little
> comfusued: )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121220/e6d1571e/attachment.htm>