[9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

[Doug Simon]

> On 9 Dec 2016, at 08:07, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Thank you, Mandy
> 
> On 12/8/16 7:46 PM, Mandy Chung wrote:
>> 
>>> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>> 
>>> It is part of JEP 295: Ahead-of-Time Compilation
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>> 
>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>> 
>> I reviewed module-info.java.*.
>> 
>> src/java.base/share/classes/module-info.java.extra
>> 
>> Now I realized jdk.vm.compiler may be excluded from JDK time at
>> build/configure time.  That explains why you can’t add these
>> qualified exports to module-info.java.
>> 
>> As we discussed offline, you can move this file to unix/classes
>> and if jdk.vm.compiler is not included in the JDK build, the build
>> tool that generates gensrc/java.base/module-info.java would filter
>> out these qualified exports.
> 
> Done. And it works.
> 
>> 
>> Related to the use of jdk.internal.misc.VM, you mentioned separately
>> that Graal uses jdk.internal.misc.VM.savedProps to find properties with
>> GRAAL_OPTION_PROPERTY_PREFIX.  Why can’t you use System.getProperties?
>> savedProps stores the properties that are removed from system properties.
>> Are Graal’s properties not in system properties?
> 
> I asked Graal guys. May be Doug can answer.


The reason we use VM.savedProps is that initialization of JVMCI and Graal is lazy (to avoid impacting VM startup) and can take place after application code has been executed. As such, we want to avoid the possibility of tampering with the system properties that configure JVMCI and Graal (i.e., all “jvmci.*” and “graal.*” properties).

-Doug