RFR (M): 7177003 C1: LogCompilation support

[Vladimir Ivanov]

 >> 7177003: C1: LogCompilation support
>> http://cr.openjdk.java.net/~vlivanov/7177003/
>
> src/share/vm/runtime/globals.hpp:
>
> -  develop(bool, CICountOSR, true,                                           \
> +  develop(bool, CICountOSR, false,                                          \
>
> Why did you change this one?  Because of the consistent method numbering?
Exactly. Otherwise, nmethod's id is ambiguous. For debugging purposes 
it's easy to explicitly enable it.

> src/share/vm/c1/c1_GraphBuilder.cpp:
>
> -    print_inlining(callee, "");
> +    print_inlining(callee, "receiver is statically known");
>
> Not sure about this change.  PrintInlining will now print this line for all inlinees.
Good catch, missed that. I agree that PrintInlining output for C1 is too 
overloaded with this change.

Formally speaking, there are 2 other messages for successful 
inlining("force inline by annotation" and "intrinsic") for C1, but these 
cases are rare.

Do you want to keep the current PrintInlining output format or does more 
compact message work as well? I'm asking because C2 prints "inline 
(hot)" message for majority of inlined methods.

I envision more detailed messages could replace generic "statically 
known", but it requires considerable code overhaul in 
GraphBuilder::invoke and I decided to leave it out for now.

Best regards,
Vladimir Ivanov

>
> -- Chris
>
>>
>> LogCompilation support in C1 - both client [1] and tiered [2] modes.
>>
>> These changes are only for Hotspot. LogCompilation tool changes will be sent separately.
>>
>> Also:
>>     - print code cache state (after each nmethod installation)
>>       Example:
>> 	 <code_cache
>> 		total_blobs='258'
>> 		nmethods='50'
>> 		adapters='133'
>> 		free_code_cache='98839808'
>> 		largest_free_block='98832512'/>
>>
>>     - consistent nmethod numbering between ordinary and OSR compilations
>
>>     - correct printing of thread id's
>>     - added missed tty locks where necessary
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> PS: actually, if it simplifies review, I can send cleanup/small enhancements as a separate change.	
>>
>> PPS: phew! Finally deciphered how deoptimization in C1 works =)
>>
>> [1] http://cr.openjdk.java.net/~vlivanov/7177003/webrev.00/compilation.client.log
>> [2] http://cr.openjdk.java.net/~vlivanov/7177003/webrev.00/compilation.tiered.log
>