Fwd: gc.log with faulty ParNew

Krystal Mok rednaxelafx at gmail.com
Wed Nov 9 07:32:48 UTC 2011


Hi Jon and Kirk,

Yes, Jon's right. The current way of doing logging needs some overhaul to
get rid of this kind of problem.

What I had in mind was something like this: instead of printing GC logs
directly to gclog_or_tty, collect them into an intermediate buffer, and
print them out as a whole at the end of the phase.

Destructors of RAII objects, such as TraceCPUTime and TraceTime, are
invoked at the end of the phases they represent, so if they can be modified
to do something more then it would have been great.

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/42a35048/attachment.htm>


More information about the hotspot-gc-dev mailing list