P4
The mx extension for JVMCI (i.e. .mx.jvmci/mx_jvmci.py) needs updating to account for changes in HotSpot, JDK9 as well as new requirements for mx based development of JVMCI compilers such as Graal:
1. To support JVMCI across different JDKs, the mx support for Graal relies on being able to query which JVMCI version is it binding to. To make this robust, the mx extension for each JVMCI version should export a JVMCI_VERSION symbol.
2. Replace --disable-debug-symbols configure option with --with-native-debug-symbols=none (JDK-8036003).
3. Need to register JVMCI JDK more eagerly to support overriding the "jvmci" tag for mx --jdk option with Graal specific JDK config (http://hg.openjdk.java.net/graal/graal-compiler/rev/22f57623221f).
4. Remove JVMCI jars from class path when running VM as they are only necessary at compile time (when compiling with a javac from JDK8 or earlier).
5. Add a JDK9_STUBS library to support compilation with JDK8 javac and Eclipse.
6. Name of the JDK bundle exported by `mx make` must include the debug level.
1. To support JVMCI across different JDKs, the mx support for Graal relies on being able to query which JVMCI version is it binding to. To make this robust, the mx extension for each JVMCI version should export a JVMCI_VERSION symbol.
2. Replace --disable-debug-symbols configure option with --with-native-debug-symbols=none (
3. Need to register JVMCI JDK more eagerly to support overriding the "jvmci" tag for mx --jdk option with Graal specific JDK config (http://hg.openjdk.java.net/graal/graal-compiler/rev/22f57623221f).
4. Remove JVMCI jars from class path when running VM as they are only necessary at compile time (when compiling with a javac from JDK8 or earlier).
5. Add a JDK9_STUBS library to support compilation with JDK8 javac and Eclipse.
6. Name of the JDK bundle exported by `mx make` must include the debug level.