FULL PRODUCT VERSION :
jdk 1.6.0_34 or jdk.1.6.0_45 (both 64 bit)

ADDITIONAL OS VERSION INFORMATION :
windows 7 64 bit

EXTRA RELEVANT SYSTEM CONFIGURATION :
here are my jvm parameters for additional gc logging

-Xloggc:${logging.dir}/gc_log.txt -verbose:gc -XX:+UseGCLogFileRotation -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=128K

A DESCRIPTION OF THE PROBLEM :
GCLogRotation does not prevent the first gc log (that has yet to exceed the GCLogFileSize jvm arg) from being erased on application start up.

The gc logs only roll while the application is running (in my case, a tomcat server), once I restart the application, the first GC log that has not met the gc file size limit is erased.

This kind of defeats the purpose of rolling GC logs imo.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use my jvm args listed in " Additional Configuration Information " on any java application

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect because I have GCLogRotation, the first GC log should not be rolled over.
ACTUAL -
I see the first GC log that has not exceeded the GCLogFileSize jvm arg, getting wiped on application restart.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Considering the behavior noted, is the same behavior before GCLogRotation was introduced, this isn't the worst thing ever.

In fact having any sort of backups for gc log is a good thing. However we restart our applications nightly, so we have scope to miss certain GC logs entries right before server restart, which is not optimal for me.