Hello, Especially for the GC log it is bad if the file is lost after a restart. It is of course possible to include PID or timestamp into the logfile, and then the truncation is no option, however if you do that you have to do your own purging. If you just want a number of generations with a fixed filename the truncation is not very good, Generally speaking why would you want to tru cate anyway? (You always have the option to delete the files if you want to feel the start,) but in all automated scenarios I cant see a good reason for truncating existing logs.
So it should be at least an option to truncate. (And if you do that, I dont think using append mode is needed). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Dmitry Samersoff <dmitry.samers...@oracle.com> To: Marcus Larsson <marcus.lars...@oracle.com>, serviceability-dev@openjdk.java.net, hotspot-runtime-...@openjdk.java.net Sent: Do., 14 Jan. 2016 16:39 Subject: Re: RFR: 8146879: Truncate new UL log files Marcus, fopen(name, "wa+") truncate file before open it in append mode. -Dmitry On 2016-01-14 18:00, Marcus Larsson wrote: > Hi, > > Please review the following patch to make sure UL truncates existing log > files before writing to them. Since files are opened in append mode, > truncation isn't done automatically, so instead the patch adds an > attempt to remove the log file before opening it. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146879 > > Testing: > Included test through JPRT > > Thanks, > Marcus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
