6950794: Make the GC log file name parameterized

Yasumasa Suenaga suenaga.yasumasa at lab.ntt.co.jp
Thu Jul 26 00:47:51 UTC 2012


I've made a patch for this RFE.
This patch allows for 4 parameters as following:

    %p - Java process' PID
    %t - date stamp when log file is created (format: YYYY-MM-DD)
    %n - if log rotation logic is enabled, then log segment id, otherwise "0"
    %% - escaped '%' character in file name

  (These parameters are defined in 6950794)

Other features of this patch:

   * The oldest log is removed. If you set -XX:NumberOfGCLogFiles=5 and
     gc.log.0 - 4 is exists, gc.log.0 is removed and gc.log.5 is created.
   * Log segment id (%n) is unsigned int . If id is UINT_MAX (0xFFFFFFFF),
     next id is zero.
   * I expanded Arguments::copy_expand_pid() . This modification affects
     -XX:OnError, -XX:ErrorFile, -XX:PerfDataSaveFile . These option also
     can use parameters that this patch provides.
     If this is not good, I can separate this feature from Arguments::copy_expand_pid() .

This patch works fine in my environment.
I would like to contribute this patch.

Please cooperate.



On 2012/07/20 9:58, Yasumasa Suenaga wrote:
> Hi Rainer,
> Do you point the following as "negative consequences" ? :
> http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-May/000613.html
> ----------------
> * "f00.00000001 might have been detected as old and copied to the remote
> host and during the same time GC decides to now reuse it... That's why
> I personally find externally organized pruning better. Another thing I
> often miss is the ability to combine size and time based rotation." (Rainer)
> The proposal never reuses log files. We'll never overwrite anything.
> Instead, we'll delete the oldest files as we create new ones. If we tell
> the users to prune the older log files themselves, I know what the first
> bug filed against the new policy will be. :-) Regarding rotating based
> on both size and time: most people care about size so I think that's
> what we'll do. If you want more advanced management of the logs you'll
> have to set N to infinity (at least we'll need a way to say "never
> delete older files") so that HotSpot doesn't delete any files and you'll
> be able to copy them and delete them yourself.
> But, seriously, this is excellent feedback. You guys are doing more wild
> stuff with our logs than I had imagined. :-)
> ----------------
> Tony says "The proposal never reuses log files. We'll never overwrite anything."
> However, seems to reuse the oldest log :-)
> hotspot/src/share/vm/utilities/ostream.cpp:
> void rotatingFileStream::rotate_log()
> We can find the oldest log with "stat" command and can check mtime of
> all logs on Linux.
> I think that "mtime" is updated every write(2) syscall .
> At least, status of this RFE is "3-Accepted" .
> So I believe that this RFE will be merge mainline someday :-)
> Thanks,
> Yasumasa
> On 2012/07/19 23:52, Rainer Jung wrote:
>> On 19.07.2012 09:56, Yasumasa Suenaga wrote:
>>> Hi,
>>> I use GC log rotation with -XX:+UseGCLogFileRotation .
>>> However, suffix of logfile is fixed ( .N : cyclic 0-(NumberOfGCLogFiles-1) ) .
>>> So I'm not easy to find the oldest log.
>>> (I have to check timestamp of file or GC event time.)
>> See the discussion thread starting at
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-May/000597.html
>> including a reply of mine on the negative consequences of the numeric naming scheme and responses of Tony to the comments on his proposal.
>> Regards,
>> Rainer
>>> I hope that this RFE is merged to JDK6/7/8.
>>> Someone is working on this RFE ?
>>> If none, I would like to contribute a patch.
>>> (Then, please someone become a sponsor of me :-) )

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logrotate.patch
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120726/4dbfcc4d/logrotate.patch>

More information about the hotspot-gc-dev mailing list