Handling large log files produced by long running Java Applications
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6941923
This RFE addresses the a problem faced by long running (one or more months) Java applications generating large log files that exhaust available disk storage. This RFE introduces a new flag -XX:logfilesize=n and its usage is described as follows: -Xloggc:somefile -XX:logfilesize=n If the value of n is 0 or is not set then current behavior. else if n is positive, close somefile when its size reaches n and direct GC log to somefile.1 until its size reaches n, close somefile.1 and dirct GC log to somefile.2 etc. A OS specific background (provided by the user) can monitor closed log files and move them to back up storage. else if n is negative perform circular logging when the file size equals abs(n)
introduced three flags:
1) -XX:+UseGCLogRotation must be used with -Xloggc:<filename>
2) -XX:NumberOfGClogFiles=<number of files> must be >=1, default is one
3) -XX:GCLogFileSize=<number>M (or K) default will be set to 512K
if UseGCLogRotation set and -Xloggc gives file name, do Log rotation, depends on other flag settings. if NumberOfGClogFiles = 1, using same file, rotate log when reaches file capicity (set by GCLogFileSize) in <filename>.0 if NumberOfGClogFiles > 1, rotate between files <filename>.0, <filename>.1, ..., <filename>.n-1 GC output through outputStream, we have multiple threads, vmThread, CMS threads, GC worker threads. Check if need rotation at every safepoint. When stop world (at safepoint), changing file handle is safe, else need grab lock to do the change. i.e. tty_lock.