6950794: Make the GC log file name parameterized
suenaga.yasumasa at lab.ntt.co.jp
Fri Jul 20 00:58:07 UTC 2012
Do you point the following as "negative consequences" ? :
* "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 :-)
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 :-)
On 2012/07/19 23:52, Rainer Jung wrote:
> On 19.07.2012 09:56, Yasumasa Suenaga wrote:
>> 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
> including a reply of mine on the negative consequences of the numeric naming scheme and responses of Tony to the comments on his proposal.
>> 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