RFR: 8167194: [JVMCI] no reliable mechanism for querying JVMCI system properties

[Doug Simon]

> On 05 Oct 2016, at 20:49, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 10/5/16 11:34 AM, Doug Simon wrote:
>> I chose system property because these properties are set with the command line system property syntax.
> 
> You mean "were set"? It use normal VM flag now.

No. The properties *are* still system properties (e.g., -Dgraal.PrintCompilation=true). The only non-standard way about how we use them is that they are accessed via VM.getSavedProperties() instead of System.getProperty() so that non-trusted code cannot influence JVMCI or Graal.
> 
>> I’d actually prefer shortening it to just “properties” if you think it doesn’t risk any ambiguity.
> 
> For me "shortening" is better - few bytes less in VM size :)

Ok, I’ll create a new webrev.

>> 
>>> On 05 Oct 2016, at 19:12, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> Why *System* properties? It is only JVMCI and Graal (or other compiler) properties. Can it be JVMCIPrintProperties? Same for messages:
>>> 
>>> [JVMCI system properties]
>>> [Graal system properties]
>>> "Selects the system compiler."
>>> 
>>> For me *system* means a machine on which JVM runs.
>>> 
>>> Does next comment still valid? System.exit(0) was removed:
>>> 
>>> PrintConfig(Boolean.class, false, "Prints VM configuration available via JVMCI and exits.”),
>> 
>> No - thanks for catching that. I’ll fixed it.
>> 
>>> 
>>> thread.cpp why use condition instead of || ?
>>> 
>>>    // 8145270: Force initialization of JVMCI runtime otherwise requests for blocking
>>>    // compilations via JVMCI will not actually block until JVMCI is initialized.
>>> +    init = init || UseJVMCICompiler && (!UseInterpreter || !BackgroundCompilation);
>> 
>> You must have looked at an earlier webrev. It’s now:
> 
> No, that is what I am suggesting. I did not know it was first version. So why use if (!init) ?

Because init may already be true:

    // Initialize JVMCI eagerly if JVMCIPrintSystemProperties is enabled.
    // The JVMCI Java initialization code will read this flag and
    // do the printing if it's set.
    bool init = JVMCIPrintSystemProperties;

I split it up like this so that I could apply comments to each bit of code that forces eager JVMCI initialization for different reasons.

-Doug

>> 
>>    if (!init) {
>>      // 8145270: Force initialization of JVMCI runtime otherwise requests for blocking
>>      // compilations via JVMCI will not actually block until JVMCI is initialized.
>>      init = UseJVMCICompiler && (!UseInterpreter || !BackgroundCompilation);
>>    }
>> 
>> -Doug
>> 
>>> On 10/5/16 8:28 AM, Doug Simon wrote:
>>>> There is currently no reliable JVMCI equivalent of -XX:+PrintFlagsFinal for listing the system properties used to configure JVMCI. This is a bug as it's important to be able to easily list flags that configure the VM. The current mechanism is to set -Djvmci.PrintFlags=true on the command line is mostly unusable as it requires adding other VM options to force  (otherwise lazy) JVMCI initialization.
>>>> 
>>>> The webrev adds a -XX:+JVMCIPrintSystemProperties flag that will print the system properties used to configure JVMCI shared code as well as whatever JVMCI compiler is configured. For example, here’s the output when no JVMCI compiler is configured:
>>>> 
>>>> java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+JVMCIPrintSystemProperties
>>>> [JVMCI system properties]
>>>> String jvmci.Compiler                = null
>>>>        Selects the system compiler.
>>>> Boolean jvmci.InitTimer               = false
>>>>        Specifies if initialization timing is enabled.
>>>> Boolean jvmci.PrintConfig             = false
>>>>        Prints VM configuration available via JVMCI and exits.
>>>> String jvmci.TraceMethodDataFilter   = null
>>>>        Enables tracing of profiling info when read by JVMCI.
>>>>        Empty value: trace all methods
>>>>        Non-empty value: trace methods whose fully qualified name contains the value.
>>>> ...
>>>> 
>>>> When Graal is configured as the JVMCI compiler, the following output shows why it’s useful to have the header lines (i.e., “[JVMCI system properties]"):
>>>> 
>>>> java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+JVMCIPrintSystemProperties --module-path=com.oracle.graal.graal_core.jar
>>>> [JVMCI system properties]
>>>> String jvmci.Compiler               := "graal"
>>>>        Selects the system compiler.
>>>> Boolean jvmci.InitTimer               = false
>>>>        Specifies if initialization timing is enabled.
>>>> Boolean jvmci.PrintConfig             = false
>>>>        Prints VM configuration available via JVMCI and exits.
>>>> String jvmci.TraceMethodDataFilter   = null
>>>>        Enables tracing of profiling info when read by JVMCI.
>>>>        Empty value: trace all methods
>>>>        Non-empty value: trace methods whose fully qualified name contains the value.
>>>> [Graal system properties]
>>>> String graal.ASMInstructionProfiling                                = null
>>>>        Enables instruction profiling on assembler level. Valid values are a
>>>>        comma separated list of supported instructions. Compare with subclasses
>>>>        of Assembler.InstructionCounter.
>>>> Boolean graal.AlwaysInlineIntrinsics                                 = false
>>>>        Unconditionally inline intrinsics
>>>> Boolean graal.AlwaysInlineVTableStubs                                = false
>>>> Boolean graal.BenchmarkCountersDumpDynamic                           = true
>>>>        Dump dynamic counters
>>>> ...
>>>> 
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8167194
>>>> http://cr.openjdk.java.net/~dnsimon/8167194/
>>>> 
>>>> -Doug
>>>> 
>>