RFC (M) 8058968: Compiler time traces should be improved
vladimir.x.ivanov at oracle.com
Wed Sep 24 13:34:17 UTC 2014
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.
> 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
>> I'm fine if these enhancements go is as separate changes though.
> So recorded:
> 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.
More information about the hotspot-compiler-dev