RFR(L): JEP165: Compiler Control

[Volker Simonis]

I also can not execute the new test
test/compiler/compilercontrol/InlineMatcherTest.java

If I execute it stand-alone like so:

jtreg -jdk /output-jdk9-hs-comp-opt/images/jdk
/OpenJDK/jdk9-hs-comp/hotspot/test/compiler/compilercontrol/InlineMatcherTest.java

I get the following error:

#section:main
----------messages:(3/245)----------
command: main ClassFileInstaller sun.hotspot.WhiteBox
sun.hotspot.WhiteBox$WhiteBoxPermission
reason: User specified action: run main ClassFileInstaller
sun.hotspot.WhiteBox sun.hotspot.WhiteBox$WhiteBoxPermission
elapsed time (seconds): 0.742
----------System.out:(0/0)----------
----------System.err:(15/781)----------
java.lang.NullPointerException
        at java.util.Objects.requireNonNull(Objects.java:203)
        at java.nio.file.Files.copy(Files.java:3002)
        at ClassFileInstaller.main(ClassFileInstaller.java:52)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:519)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
        at java.lang.Thread.run(Thread.java:746)

It seems the test description is missing the following build tag
before the run tag:

 * @build InlineMatcherTest ClassFileInstaller sun.hotspot.WhiteBox
jdk.test.lib.*

However if I add that, I get the following compilation error:

/OpenJDK/jdk9-hs-comp/hotspot/test/compiler/compilercontrol/InlineMatcherTest.java:144:
error: cannot find symbol
                int result =
WHITE_BOX.matchesInlineMatcher(testTarget, pattern);
                                      ^
  symbol:   method matchesInlineMatcher(Method,String)

I suppose his is because your top-level change adds:

+   public native int     matchesInline(Executable method, String pattern);

to the WhiteBox class, but the test uses matchesInlineMatcher(). If I
change that to matchesInline() I still get another error:

java.lang.RuntimeException: exception on getting method Helper.innerHelper
        at InlineMatcherTest.getMethod(InlineMatcherTest.java:117)
        at InlineMatcherTest.test(InlineMatcherTest.java:64)
        at InlineMatcherTest.main(InlineMatcherTest.java:106)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:519)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
        at java.lang.Thread.run(Thread.java:746)
Caused by: java.lang.NoSuchMethodException:
InlineMatcherTest$TestCases.innerHelper()
        at java.lang.Class.getDeclaredMethod(Class.java:2163)
        at InlineMatcherTest.getMethod(InlineMatcherTest.java:115)
        ... 8 more


This was the point where I stopped my investigations.
Can you please fix the test to run correctly?

Thanks,
Volker


On Wed, Sep 23, 2015 at 4:39 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> 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