RFR(L): JEP165: Compiler Control

[Nils Eliasson]

Hi Zoltan,

All the CompileCommand options work in the same way as described in the 
intrinsics-mail. In compilerDirectives.hpp the flags are declared with 
their CompileCommand equivalent. And in 
compilecommand_compatibility_init the directives may be updated with 
these flags.

Take a look at 
test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java 
for an example of how it can work. First these are set on the 
commandline "-XX:-PrintAssembly -XX:CompileCommand=print,*.*", then in 
the test a directive is loaded that turns it off. Later the directive is 
removed. The result is verified at each step.

I hope my explanation is understandable.

Best regards,
Nils Eliasson




On 2015-10-06 16:16, Zoltán Majó wrote:
> Hi,
>
>
> there is another question that comes to my mind.
>
> For command-line flags that allow per-method usage you propose to get 
> the flag's value from the directive instead of getting the value using 
> ciMethod()::has_option_value(). For example, you propose to use
>
> _vector_loop_debug = directive()->VectorizeDebugOption;
>
> instead of
>
> method()->has_option_value("VectorizeDebug", _vector_loop_debug);
>
> You propose to do this for almost all flags (e.g., VectorizeDebug, 
> DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, 
> CompileThresholdScaling. Could you please explain why?
>
> Thank you and best regards,
>
>
> Zoltan
>
> On 10/02/2015 04:10 PM, Nils Eliasson wrote:
>> Hi all,
>>
>> A new webrev with all the feedback from reviewers and others.
>>
>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/
>>
>> - name changes as requested by christian
>> - various small bug fixes
>> - New tests for sanity testing flags and their behaviour with vm 
>> flags and compile commands present
>>
>> Regards,
>> Nils
>>
>> On 2015-09-22 19:21, Nils Eliasson wrote:
>>> Hi,
>>>
>>> This is the initial RFR for JEP165: Compiler Control. This feature 
>>> enables runtime manageable, method dependent compiler flags. 
>>> (Immutable for the duration of a compilation.)
>>>
>>> The change includes:
>>> - A parser for the directives format (json like) including vmtests 
>>> (json.cpp/hpp)
>>> - A component for construction of compiler directives 
>>> (directivesParser.cpp/hpp)
>>> - The directives including the option definitions, default values 
>>> and compilecommand relations (compilerDirectives.cpp/hpp)
>>> - Diagnostic commands for working with the directives - installing, 
>>> removing, printing
>>> - Lots of small changes wherever we access flags or legacy 
>>> compilecommands in the compiler
>>>
>>> Notes:
>>> The feature is documented in the JEP 
>>> (https://bugs.openjdk.java.net/browse/JDK-8046155).
>>>
>>> Currently only a small amount of compiler flags are included in the 
>>> change. The flags are a representative selection of different types 
>>> targeting both compilers. All of them existed as CompilerOracle 
>>> option commands. Two commands was not included in the directives due 
>>> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both 
>>> are accessed from runtime (outside any compiler) and requires some 
>>> special handling. (Solved but not implemented.)
>>>
>>> Full backwards compatibility with CompileCommands is implemented but 
>>> can be turned off with flag -XX:CompileCommandCompatibilty. Also 
>>> meta handling the compatibility flag by supporting it in the 
>>> directives (test feature).
>>>
>>> The change contain some rough edges that will polished over the 
>>> coming days.
>>>
>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155
>>> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/
>>> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/
>>>
>>> Please review!
>>>
>>> Best regards,
>>> Nils Eliasson
>>
>