JDK-8075796 : [Event Request] Add more compilation related information to JFR
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-03-24
  • Updated: 2019-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Cloners :  
Relates :  
Relates :  
Description
Here is the JFR wishlist from 360 Treasury Systems:
"In regards to a "wishlist" for more information: we did have a problem recently with a full code cache and sometimes not compiled code. It is possible to see compilation times in JFR, but I'm missing the details of the -XX:+PrintCompilation. How much L1, L2 compilations we have (-XX:+TieredCompilation). How much percent is called in compiled vs. optimized compiled vs. interpreted methods? How much code cache do we need? Is it worth to activate aggressive optimizations? Does it make sense to tune the inlining (-XX:MaxInlineSize)? Of course no compilation is the worst case, but as the difference between compiled and non-compiled code is very big, more insights are good. There are -XX options for further logging, but it's certainly more painful to analyze them then having it in JFR. I can see the compiled methods, the size, OSR but the question is what conclusions derive from there." 

Here is a list from EM:

- Code Cache usage
- Is compiler shut down?
- Access to sweeper data
- Compiled method hotness ranking (query per method, query top N)
- Content of code cache
Comments
Most of these are already done.
23-03-2018