Request for review: 6941923: RFE: Handling large log files produced by long running Java Applications

[yumin.qi at oracle.com]

  Thanks for pointing this out,  only manageable flags can be changed 
from outside.
  If change UseGCLogFileRotation to manageable, means it can be changed 
during java app running. So it can be switched on and off if -Xloggc: 
gives a file name. As you pointed out, if this flag is manageable, it 
should go file a CCC request since it can be changed by outside tools. I 
agree with you that no need to do so now.

Yasumasa's suggestion is add one more cmd in AttachOperationFunctionInfo 
[] as "gclogrotate", if UseGCLogFileRotation is on, this cmd will call 
gclog_or_tty->rotate_log(), else print out err msg.

I am not sure if I understand  the suggestion well.  If this way, it has 
no harm to the existing implementation since the log is already in 
rotation. It also has no effect to the logging mechanism.

What I thought is that what if outsider changes UseGCLogFileRotation 
when java is running,  now it is not a problem --- not an external flag.

I will keep the current implementation.

Thanks
Yumin


On 4/13/2011 10:30 AM, Y. S. Ramakrishna wrote:
> But I agree with Jon that that would be a further new RFE,
> rather than doing all of that at once.
>
> Also, since the flags seem to be designed as a supported public 
> interface,
> a CCC (or appropriate) review request should be filed, so that
> any changes stemming from that review are addressed before
> this is pushed...
>
> -- ramki
>
> On 04/13/11 10:24, Y. S. Ramakrishna wrote:
>> A possibility to pursue:
>>
>> You could make the appropriate flags manageable, and 
>> re-sample/re-snapshot
>> into private variable (and when appropriate re-initialize the streams)
>> at each safepoint where you now just check for log rotation.
>>
>> -- ramki
>>
>> On 04/13/11 09:54, yumin.qi at oracle.com wrote:
>>>  Current implementation will not work with outside tool, 
>>> ostream_init called once in JVM starting and flags will not be 
>>> changed rest of running supposedly. Now need to think of what if 
>>> flags changed by outside tool.  Need reconsideration of changing 
>>> flags from outside tool.
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/13/2011 8:47 AM, Jon Masamitsu wrote:
>>>> Yasumasa ,
>>>>
>>>> Sounds like this is a request for an enhancement of the
>>>> feature that Yumin has implemented.   Or rather maybe
>>>> just a way of turning it on?  Or is it something more basic
>>>> to the feature?
>>>>
>>>> Jon
>>>>
>>>> On 4/12/2011 5:55 PM, Yasumasa Suenaga wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> I would like to rotate GC log triggered by the outside.
>>>>> I think that it can be implemented using AttachLister 
>>>>> (AttachOperationFunctionInfo [])
>>>>> and invoker tool.
>>>>>
>>>>> Could you examine it?
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>> (2011/04/13 3:41), yumin.qi at oracle.com wrote:
>>>>>> http://cr.openjdk.java.net/~minqi/6941923/webrev.00/ 
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/6941923/webrev.00/>
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> This is a RFE request for having a GC log rotation to prevent 
>>>>>> Java application from over flooding disk with GC output running 
>>>>>> for long time.
>>>>>> In the implementation, supply three JVM options
>>>>>> 1) -XX:+UseGCLogFileRotation must be used with -Xloggc:file
>>>>>> 2) -XX:MaxGCLogFileNumbers= set limit of rotation file numbers, 
>>>>>> default to 1, maximum set to 1024.
>>>>>> 3) -XX:GCLogFileSize= can be configured by user how big the file 
>>>>>> size should be. Default to 10M. Minimum set to 512K if given from 
>>>>>> option is less than 512K.
>>>>>>
>>>>>> If MaxGCLogFileNumbers=1, rotating output in same file, i.e write 
>>>>>> from beginning of the file when reach cap of the file; with 
>>>>>> MaxGCLogFileNumbers > 1 rotating files sequentially after reach 
>>>>>> cap in file, file.1, file.2, ..., file.<MaxGCLogFileNumbers-1> 
>>>>>> then back to file, file.1, ...
>>>>>> Check if rotation needed at safepoint ending.
>>>>>>
>>>>>> Tested with multiple GC choices.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>>
>>