RFR(L): JEP165: Compiler Control
Zoltán Majó
zoltan.majo at oracle.com
Tue Oct 6 14:16:04 UTC 2015
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
>
More information about the hotspot-compiler-dev
mailing list