This is something that a lot of developers have asked for given that they were concerned with the GC logs getting very large. Given that each GC log record is of variable size, we cannot easily cycle through the log using the same file (I'd rather not have to overwrite existing records). Our current proposal is for the user to specify a file number N and a size target S for each file. For a given GC log -Xloggc:foo, HotSpot will generate

foo.00000001
foo.00000002
foo.00000003
etc.

(we'll create a new file as soon as the size of the one we are writing to exceeds S, so each file will be slightly larger than S but it will be helpful not to split individual log records between two files)

When we create a new file, if we have more than N files we'll delete the oldest. So, in the above example, if N == 3, when we create foo.00000004 we'll delete foo.00000001.

Note that in the above scheme, the logs are not really "cyclic" but, instead, we're pruning the oldest records every now and then, which has the same effect.

The sequence numbers should be 0 padded, either with 6 or 8 zeros (seriously 6 should be more than enough).

If N == 1 (default), no sequence numbers will be appended to the log name. We should also allow the user to say "don't delete any segments" (with N == 0 perhaps?).

During a recent discussion on the openjdk lists:

http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-May/000597.html

some developers also recommended to maybe cycle the logs not only based on size but also based on time (i.e., at midnight every night).