Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes

[Vladimir Ivanov]

John,

Thanks for the clarification.

I agree that compiler's <task> section is the best fit for such info.
What I would like to see is clearer format and denser data 
representation, so it isn't burdensome to parse it by automatic tools 
(like LogCompilation).

But I still have one unclear point. It's more methodological and relates 
to VM logging in general. Do we have a habit to look for warnings in 
compilation logs? :-)

When a warning is issued during node count verification step, it doesn't 
occur on console. I would duplicate it both on console & in the log 
then. But, I rely on my own habits here - if I request such checks 
explicitly, I would like to easily see them.

Best regards,
Vladimir Ivanov

On 10/30/12 11:27 PM, John Rose wrote:
> On Oct 30, 2012, at 7:48 AM, Vladimir Ivanov wrote:
>
>> Regarding the currently published version, I think that logging part can
>> be improved further.
>
> Those are good suggestions, Vladimir.
>
>> The general question is: do you intentionally print this info into XML
>> compiler log? Why don't you use tty instead? All the messages will
>> appear on console and will be duplicated in <tty> section in XML log
>> anyway and you don't need to bother too much about the format.
>
> Each compiler thread has a separate log section, divided in the <task>s
> executed by that thread.
>
> The main <tty> log is global, and intended for globally serialized
> runtime events, such as deoptimizations or GCs or tty->print stuff.
>
> Meanwhile, the compiler (in one more more threads) runs asynchronously
> to all the Java application threads.  So it gets a separate log.
>
> If an interesting event occurs within the time-sequence of a compiler
> task, it should be logged in that compiler thread's C->log.
>
> When the JVM exits, all the extra compiler logs are catted together onto
> the end of the main log's output file.
>
> — John