JDK-8065641 : JEP-JDK-8046155: Compiler Control - Performance Plan
  • Type: JEP Task
  • Component: performance
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Fix Versions: 9
  • Submitted: 2014-11-21
  • Updated: 2015-11-12
  • Resolved: 2015-11-12
Related Reports
Blocks :  
JDK-8138751 - JEP 165 (CompilerControl) changes break JMH @CompilerControl tests
Blocks :  
JDK-8046155 - JEP 165: Compiler Control
Relates :  
JDK-8057169 - Improve CompilerOracle matchers search
Description
Compiler controls are essential for performance testing and benchmarking.
JMH uses compiler controls extensively to provide a reliable benchmarking environment.
As the part of performance studies for compiler control project, we would need to see
that proposed implementation does not regress current compiler control mechanisms,
as well as provides a consistent performance for it.

Specific concerns:

a) The functionality of -XX:CompileCommand=... and -XX:CompileCommandFile=...; both are used by JMH, mostly with inline/dontinline modes.

b) The performance of -XX:CompileCommand=... and -XX:CompileCommandFile=...; there is already known issues (JDK-8057169) that should not get worse with this change.
Comments
The performance work for this JEP is done.
12-11-2015
http://cr.openjdk.java.net/~neliasso/8046155/webrev.06/ - fixes JDK-8138751 - still works fine with JDK-8057169, in 1m02s, and now the GraphBuilder::should_inline branch reappeared in profiles
06-10-2015
Quickly analyzing the latest webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ The test from JDK-8057169 improves significantly: 1m54s user time --> 46s user time, the GraphBuilder::should_inline branch is gone from the profiles.
02-10-2015
However, it appears to regress JMH core benchmarks that test @CompilerControl functionality, see JDK-8138751.
02-10-2015