RFC (M) 8058968: Compiler time traces should be improved
aleksey.shipilev at oracle.com
Wed Sep 24 13:22:13 UTC 2014
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the hotspot-compiler-dev