RFR(L): JEP165: Compiler Control

[Volker Simonis]

Hi Nils,

in general I like the new approach although I haven’t looked at all
the changes in detail.

For now I only have one remark:

- in json.hpp you are declaring strchrnul() for non-Linux systems but
the function isn't used there so the declaration isn't necessary.

- in json.cpp you are defining strchrnul() for non-Linux systems. But
this is shared code and this function is a GNU extension. I would
prefer if you unconditionally define your own version of the function
(e.g. as strchrnul_() with a comment that the original variant is only
available on GNU systems) to get rid of the preprocessor macros in
shared code. If you absolutely want to keep the native version on
Linux please use:

#ifndef _GNU_SOURCE
// strchrnul() is a GNU extension
const char* strchrnul(const char *s, int c) {
  const char* tmp = strchr(s, c);
  return tmp == NULL ? s + strlen(s) : tmp;
}
#

this will automatically work on AIX (and potentially other, non-GNU systems).

Thanks,
Volker


On Tue, Sep 22, 2015 at 7:21 PM, Nils Eliasson <nils.eliasson at oracle.com> 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