RFC (M) 8058968: Compiler time traces should be improved

[Aleksey Shipilev]

Thanks, Vladimir!

More reviews, please :)

-Aleksey.

On 09/24/2014 05:34 PM, Vladimir Ivanov wrote:
> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 9/24/14, 5:22 PM, Aleksey Shipilev wrote:
>> On 09/23/2014 08:57 PM, Vladimir Ivanov wrote:
>>> Looks good to me. Thanks for taking care of this long-standing cleanup.
>>
>> Thanks for review, Vladimir!
>>
>>> As a request for further improvements, I'd like to see the following:
>>>
>>> * More fine grained details about "Incremental Inline"
>>>    We do additional optimization passes during incremental inlining, so
>>> it'd be great to see where we actually spend time.
>>
>> Done:
>>   http://cr.openjdk.java.net/~shade/8058968/webrev.02/
>>
>> I also cleaned up formatting, and put a bit more probes in other places.
>> This patch finally passes JPRT (modulo some unrelated LF tests
>> failures), and I think it is ready for prime-time.
> 
>>
>> Please review and sponsor!
>>
>>> * The following information segregated by compiler type (C1/C2):
>>>    Total compiled methods   :  19359 methods
>>>      Standard compilation   :  19298 methods
>>>      On stack replacement   :     61 methods
>>>    Total compiled bytecodes : 4777417 bytes
>>>      Standard compilation   : 4717650 bytes
>>>      On stack replacement   :  59767 bytes
>>>    Average compilation speed:  20330 bytes/s
>>>
>>>    nmethod code size        : 107922240 bytes
>>>    nmethod total size       : 201508520 bytes
>>
>> Alas, these counters are also fed into JMX events, and so a bit more
>> careful rewrite is required to separate for C1/C2 here.
>>
>>> * Additional statistics about Tiered compilation (compilation task
>>> counts per level) would be useful here as well.
>>
>> Ditto, and we would also probably like to expose these things in JMX/JFR
>> events.
>>
>>> I'm fine if these enhancements go is as separate changes though.
>>
>> So recorded:
>>    https://bugs.openjdk.java.net/browse/JDK-8059020
>>
>> Current change already covers enough complexity, and provides quite a
>> few insights into compiler performance, so I would like to see this
>> pushed in first without stalling for other feature suggestions.
>>
>> Thanks,
>> -Aleksey.
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140924/70209741/signature.asc>