JDK-8241557 : Avoid cloning DirectiveSet at runtime if -XX:CompileCommand is set
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13,14,15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-03-24
  • Updated: 2020-04-01
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
Relates :  
JDK-8057169 - Improve CompilerOracle matchers search
Relates :  
JDK-8241556 - Memory leak if -XX:CompileCommand is set
Relates :  
JDK-8046155 - JEP 165: Compiler Control
Description
Currently the handling for -XX:CompileCommand is not efficient: 
DirectiveSet::compilecommand_compatibility_init() clones the current instance of DirectiveSet, checks and modifies with existing options in CompilerOracle, then returns the new instance, or frees up the new instance and returns the current instance. This happens every time the JIT compiles a method. This cloning mechanism also partly caused the memory leak in JDK-8241556.

It should be possible to convert all CompileCommand options into equivalent DirectiveSet objects during startup, so it can avoid the cost of allocation, deallocation, and some comparison work at runtime.
Comments
Thanks for confirming the plan for "-XX:NewCompilerCommand" interface. Is there a bug for it? > [~manc] The title and description in this bug deosn't match your comment. Have the bugs been mixed up? The story is that I found and fixed the memory leak in JDK-8241556, then I found an optimization opportunity to not clone DirectiveSet if CompileCommand is set, thus opened this bug. My first comment explains that we don't actually need to do this optimization, if there's a plan to implement the "-XX:NewCompilerCommand" interface and fully deprecate the old CompileCommand. So if there's a bug for the "-XX:NewCompilerCommand" interface, feel free to close this bug as work-as-intended.
01-04-2020
To comment the bug that is mentioned in the title: The DirectiveSet is not supposed to be cloned if there are no CompileCommands - see CompilerOracle::has_any_option() https://hg.openjdk.java.net/jdk/jdk/file/a078359893a5/src/hotspot/share/compiler/compilerDirectives.cpp#l240
01-04-2020
[~manc] The title and description in this bug deosn't match your comment. Have the bugs been mixed up?
01-04-2020
Yes - this has been the plan. It just hasn't been top priority. I imagine the new flag should be something like : -XX:NewCompilerCommand=method=<method-pattern>,<option>=<value>,<option=value> etc.... The format should probably be similar to other multi options flags like how JFR StartFlightRecording or -Xlog does it. Care should taken to keep as close as possible to existing flags. In the best case we should be able to reuse an existing command line parser utility. Pros + More efficient to use command line than directives files when handling simple flags + Avoid repetitive CompileCommands like how CompilerOracle does it + Can finally get rid of the Stringly typed options to CompilerOracle. + When CompileCommand is fully replaced then a lot of backwards compatibility logic can be removed.
01-04-2020
The main reason why we are interested in optimizing handling of CompileCommand, instead of suggesting users to move to the new compiler control interface in JEP-165, is the convenience for deployment from using a single CompileCommand flag that contains all necessary values. The new "-XX:CompilerDirectivesFile=" interface requires specifying and maintaining a separate JSON file. This extra file complicates the deployment process for our production users. In practice, the most commonly used directive in production is to exclude the compilation of some methods (in order to work around some compiler bugs). Such directives could be easy specified in a short string for CompileCommand. If the new interface could provide a similar JVM flag (say -XX:CompilerDirectivesValue) that takes an inlined value instead of a path to JSON file, we would happily move our users to the new interface, and drop this RFE request.
25-03-2020