two trivial bug about UseGCLogFileRotation and CMSDumpAtPromotionFailure ?

谢良 xieliang at xiaomi.com
Thu Dec 20 08:57:29 UTC 2012


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/e7d7fc9c/attachment.htm>


More information about the hotspot-gc-dev mailing list