gclog improvements

[Jon Masamitsu]

There's a project to define a common standard for
logging in J2SE and J2EE.  If that happens then
there is a second project to make the VM logging
fit into that same infrastructure.  One of the
hopes was that an application could see logs
from the VM through a well defined API.


On 10/14/08 11:48, kirk wrote:
> Hi Jon,
> 
> Ok, now I'm scared ;-) What do you mean by "work on that logging 
> overhaul"? I've got a bit invested in the status quo and while I'm all 
> for an overhaul, it would be nice to understand what is on the table.
> 
> Regards,
> Kirk
> 
> Jon Masamitsu wrote:
>>
>>
>> On 10/14/08 09:42, kirk wrote:
>>> Hi,
>>>
>>> IBM does log rollovers and IMHO it's a reasonable feature request. It 
>>> makes it easier to leave verbose gc turned on in production.
>>
>> It is a reasonable feature and it would
>> probably fit into an overhaul of the logging
>> infrastructure that is on the to-do list
>> of the runtime guys.  However, there is no one
>> available to work on that logging overhaul
>> so I would not be too hopeful.
>>
>>>
>>> Regards,
>>> Kirk
>>>
>>> Rainer Jung wrote:
>>>> Tony Printezis schrieb:
>>>>  
>>>>>> Unfortunately the gclog gets overwrittten each time the JVM starts 
>>>>>> due
>>>>>> to the way the file gets opened. So in order to keep the files people
>>>>>> need to add rotation commands to their start scripts. Often this 
>>>>>> doesn't
>>>>>> happen and especially when emergency restarts where needed, the old
>>>>>> gclog is gone.
>>>>>>
>>>>>> Any plans for changing this? Or maybe even adding log file 
>>>>>> rotation to
>>>>>> the gclog?
>>>>>>         
>>>>> We don't have any immediate plans for doing this. Regarding the log 
>>>>> file
>>>>> getting overwritten, typically customers launch the JVM from a script
>>>>> and it's easy to create a unique GC log file name from a script 
>>>>> (append
>>>>> the start time, pid, or something like that). So, that's an easy issue
>>>>> to solve...
>>>>>     
>>>>
>>>> Yes, but I do now see a lot of customers running their midrange server
>>>> apps on Windows. Those are of course services started by Java service
>>>> wrappers, which are not themselves easily scriptable. Especially
>>>> automatic restarts triggered by built-in watchdogs do not have any
>>>> scripting mechanism.
>>>>
>>>>  
>>>>>> Furthermore: Until now there is no event based model of monitoring 
>>>>>> the
>>>>>> GC and Memory data. All methods apart from logging are based on a 
>>>>>> pull
>>>>>> model, that retrieves information in regular intervals. The most
>>>>>> important information does not exist in regular intervals, but 
>>>>>> instead
>>>>>> immediately after a GC. It would be nice to have some event based 
>>>>>> model
>>>>>> (e.g. like in JVMTI), that allows to track the same data as the gc
>>>>>> logging, without using the historically motivated gclog file format.
>>>>>>         
>>>>> There's a trade-off. I don't like the pull method myself, given 
>>>>> that it
>>>>> can skip events, give you inconsistent information, etc. But, to get
>>>>> consistent information you generally have to do a STW pause, and 
>>>>> this is
>>>>> too much of an overhead for an application in production. This is 
>>>>> why a
>>>>> lot of the monitoring has been implemented asynchronously.
>>>>>     
>>>>
>>>> So there is a problem in getting a perfect solution. An approximation
>>>> could be:
>>>>
>>>> - provide a buffer with the information obtained after the last
>>>> Minor/Major GC (e.g. GC type, count, total and filled sizes of the
>>>> various memory regions, durations of the last run)
>>>>
>>>> - fire an asynchronous event (not STW) to allow agents to retrieve the
>>>> buffered data
>>>>
>>>> That's a hybrid, that would try to provide some benefits of the event
>>>> model, without risking long STW pauses. Of course one would have to
>>>> think about synchronizing read/write access to the buffer, but without
>>>> an actual agent running, there would be no contention, and with an 
>>>> agent
>>>> running there would be only noticable performance impact, if there were
>>>> lots of GCs and additionally the agent did expensive operations while
>>>> retrieving the buffers.
>>>>
>>>> Regards,
>>>>
>>>> Rainer
>>>>
>>>>   
>>>
>>
>>
>