gc.log with faulty ParNew

[Charles K Pepperdine]

Hi Krystal,

I'm thinking that if we're looking to do this in one shot, it's never going to get done. I don't care if the log records are time ordered. I don't care if we happen to lose one or two of them. In some cases I'll simply delete corrupted records from the log file. Missing a few out of thousands makes very little difference in the analysis.

I was thinking that maybe the gclog_or_tty could be replaced with a set of buffers. Writes would end up in the buffers. This is where things get a little fuzzy as I don't understand all of the intricacies of the code. But, maybe there is a way to have the GC thread dump the buffer just at the end of it's phase with the exception of CMS. Though might delegate the dumping of CMS records to the young gen collector. All the CMS collector would offer it's log records to the YG collector when it's done.

Regards,
Kirk

> 
> Unfortunately the current way of logging directly uses the global tty, gclog_or_tty, xtty in a lot of places throughout the code, and RAII objects aren't supposed to be passed around. I tried to modify TraceTime to get this fixed, but it got quite messy.
> 
> Would it be okay if:
> A thread-local hook is added to outputStream, and allow those RAII objects to keep a buffer and register thenselves to the hook (nested ones get chained up), and that whenever an outputStream object receives a print/stamp sort of method call, it delegates the call to the registered buffers; and finally in the RAII objects' destructors, unregister from the outputStream and write out the buffered contents.
> 
> This way the code that use gclog_or_tty directly would stay the same, and we may get logs that look more intact but doesn't always keep the ordering of events.
> 
> If it sounds like a possible solution, I'd volunteer to write a prototype for it. Don't know how it'd conflict with the standardizing of logging, though.
> 
> Regards,
> Kris Mok
> 
> On Wed, Nov 9, 2011 at 12:22 AM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> Kirk,
> 
> Sorry but there is nothing I'm aware of that will fix this
> problem with the current way of doing logging.   It plagues
> us as much as anyone but no one has screamed "I can't
> take it anymore"  and fixed it.
> 
> Jon
> 
> 
> On 11/07/11 13:49, Charles K Pepperdine wrote:
>> Hi all,
>> 
>> Line 15 of this log file has a ParNew record split by the end or an abortable-preclean. Is there a way to prevent the gc log records from being corrupted in this way? This is not the only place it happens and it makes an already impossible task of scanning these things much harder.
>> 
>> Regards,
>> Kirk
>> 
>> 
>> Begin forwarded message:
>> 
>> =
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111109/46539496/attachment.htm>