6950794: Make the GC log file name parameterized

John Cuthbertson john.cuthbertson at oracle.com
Thu Aug 9 19:35:17 UTC 2012


Hi Yasumasa,

Thanks for contributing the patch.

There are a couple of reasons why no-one has volunteered to sponsor your 
patch yet. The first is that most of our team (and specifically the 
engineer who is looking at improving the whole GC logging) are out on 
vacation. They should start to come back later this month. Another 
reason is that changes to commonly used command line flags tend to be 
controversial and generate a fair amount of discussion and argument. So 
we also want to give the OpenJDK community a chance to try out your 
patch and comment and have some level of consensus before it is sponsored.

Thanks,

JohnC

On 08/08/12 18:38, Yasumasa Suenaga wrote:
> 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 :-) )
>>




More information about the hotspot-gc-dev mailing list