Request for review: 6941923: RFE: Handling large logfiles produced by long running Java Applications

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Mon May 9 01:40:34 PDT 2011


Rainer,

Appending rather than overwriting would not fix the problem you mention. Since 
we are talking about a rotating log file, the old log would be overwritten 
eventually anyway.
Also, if we append, it would be virtually impossible for the average user to 
find where the new log starts. As a matter of fact, I'm not sure how that 
would work in this new scheme either... One would have to look at the file 
creation dates I assume. But at least when overwriting, the content of the log 
files would only belong to one JVM run.

There are a few other ways to keep the old log around that I think would make 
more sense than opening the log in append mode:

* If the JVM finds an old log file at startup it could warn, possibly even 
refuse to start. (... and destroy quite a few customer installations out there 
that relies on restarting the JVM instantly if it goes down.)

* If an old logfile is found at startup the JVM could rename the old log by 
adding its creation date or something. (... and start filling the disk with 
old log files.)

I think all of the above (including appending the log file) could be 
interesting features to have behind a flag. But I doubt that any of the 
alternatives would be a preferred default behavior for Hotspot.

Regards,
/Jesper

On 05/07/2011 02:36 PM, Rainer Jung wrote:
> I know this is not directly the topic of this page, but I think it is directly
> related: gc log files are opened for write, but not append. So each time the
> jvm is started, previous log files get overwritten. This is especially bad,
> since often when something goes wrong admins try to fix by restarting, thus
> overwriting the old gc data and making a posteriori analysis impossible.
>
> Of course more advanced admins have learned, that they should not use a fixed
> file name for the gc log file name, but instead add some startup timestamp to
> the file name chosen for -Xloggc, thus starting the JVM with a new file each
> time (or copying the old file before restart).
>
> But I expect lots of admins are still not aware of this problem.
>
> I guess not opening the file for append was either an omission from the
> beginning, or an inadequate measure to cope with large gc logs by at least
> purging them during each JVM restart. The latter - handling large gc log files
> - is the topic of this RFE.
>
> So I suggest to open the log files for append in order to not have overwritten
> important analytical data on each restart. I know it is an incompatible change
> of behaviour, but that part of the behaviour was never specified and I
> personally expect more users to see a benefit in the change than not.
>
> Regards,
>
> Rainer


More information about the hotspot-gc-dev mailing list