JEP 165: Compiler Control
|Status||Proposed to Target|
|Component||hotspot / compiler|
|Discussion||hotspot dash compiler dash dev at openjdk dot java dot net|
|Reviewed by||Jesper Wilhelmsson|
|Endorsed by||Mikael Vidstedt|
|Relates to||8027829: CompileCommand does not accept all JLS-conformant class/method names|
|8027711: Unify wildcarding syntax for CompileCommand and CompileOnly|
|8050853: Extend -XX:CompileCommand to include an option that always compiles the specified method|
Improve control of the JVM compilers by encapsulating control into a set of options. Allow different option sets to be applied depending on which method is being compiled. Add the possibility of changing the option sets during run time.
Fine-grained and method-context dependent control of the JVM compilers (C1 and C2).
The ability to change the JVM compiler control options in run time.
No performance degradation.
Method-context dependent control of the compilation process is a powerful tool for writing small contained JVM compiler tests that can be run without restarting the entire JVM. It is also very useful for creating workarounds for bugs in the JVM compilers. A good encapsulation of the compiler options is also good hygiene.
Gather all options that control the JVM compilers into a set of options. The set is called a compiler directive and is an instruction for how to compile. A directive is supplied to the VM together with a method matcher that decides what methods it applies to. Several directives can be active in the runtime at the same time. Directives can be added and removed during run time.
Directives can be defined in a standardized and human readable file format.
Different ways of adding and removing directives will be investigated. This includes command line, diagnostic command and Java API.
For verification purposes the current set of directives can be dumped from diagnostic command. The directives will also be printed when the compiler or VM enters a fatal state.
The JVM compiler is responsible to only respect directives that produce correct code.
Tests for all introduced APIs and for the directives format will be needed. Test for the most common use cases will include:
- Work-around use case 1: Turning off an optimization for a specific method
- Work-around use case 2: Disallow inlining of method A in compile of method B
- Crash use case: Verify directives in text error dump
- Test use case 1: Install directive during runtime and verify effect
- Test use case 2: Extract active set of directives
Risks and Assumptions
The sheer amount of compiler options will limit us to focus on a subset initally.
- Diagnostic command - Already in place
- Working with full JDK - Already in place
- Documentation: Flags and API
- CCC: A CCC request will be required for directives format, JVM compiler flag changes and API.
- Performance: Standard regression testing