FULL PRODUCT VERSION :
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.32-t14.el5 x86_64 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
openjdk-7-ea-src-b145-07_jun_2011

A DESCRIPTION OF THE PROBLEM :
In ostream.cpp, the logfile for loggc is opened via a fileStream:

 if (Arguments::gc_log_filename() != NULL) {
   fileStream * gclog = new(ResourceObj::C_HEAP)
                          fileStream(Arguments::gc_log_filename());

The fileStream constructor always opens files with 'w':

fileStream::fileStream(const char* file_name) {
 _file = fopen(file_name, "w");
 _need_close = true;
}

This means that in a long-running process, one cannot rotate the gc log with the common copy-truncate strategy, because the file handle holds on to the previous byte position. Previous bytes will be nulled out, but the file will never shrink in size.

Instead the file should be opened with 'a'.

This appears to affect JDK7, at least in package openjdk-7-ea-src-b145-07_jun_2011.zip.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start a process with -Xloggc:/tmp/gc.log.

Truncate /tmp/gc.log via "bash -c '> /tmp/gc.log'" or similar.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The file decreases in size.
ACTUAL -
The file stays the same size, but is nulled out.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
There is no workaround except to restart the java process.