6950794: Make the GC log file name parameterized

[Yasumasa Suenaga]

Hi,

A few weeks ago, I posted a patch for implementing this RFE.

@OpenJDK tweets my proposal :-)
http://twitter.com/OpenJDK/status/232506237546295297


Advantages of this patch is that name of gc log can be defined by
state of run-time. So we can define gc log name which depend on
PID, start date of VM. And we can find the newest or the oldest
log easily.

For example, multiple VM is running on 1 OS and each VM writes
gc log. Each VM is same setting and runs same application.
If we set "-Xloggc:gc-%p.log", we can find log of specific VM easily.


I'm sure that this patch helps us to operate gc logs.
Please cooperate.


Thanks,

Yasumasa


On 2012/07/26 9:47, Yasumasa Suenaga wrote:
> Hi,
>
> 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.
>
>
> Thanks,
>
> Yasumasa
>
>
> 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 :-) )
>