I lost track a bit but why are we exporting jdk.vm.ci.services to the world now?
module jdk.internal.vm.ci { - exports jdk.vm.ci.services to jdk.internal.vm.compiler; + exports jdk.vm.ci.services; > On Apr 18, 2017, at 9:16 PM, Doug Simon <doug.si...@oracle.com> wrote: > > (adding hotspot-compiler-dev) > > Please review these changes that make jdk.internal.vm.compiler an upgradable > compiler. > The primary requirement for this is to remove all usage of JDK internals from > Graal. > While this most involves changes in Graal, there remain a few capabilities > that must > be exposed via JVMCI. Namely: > > 1. Graal needs a copy of jdk.internal.misc.VM.savedProps so that it can Graal > initialize > can use system properties that are guaranteed not to have been modified by > application > code (Graal initialization is lazy and may occur after application code has > been run). > > 2. Truffle needs to be able to trigger JVMCI initialization so that it can > select the Graal > optimized implementation of the Truffle runtime. > > These capabilities have been added to jdk.vm.ci.services.Services. A comment > has > also been added to this class to denote the current methods to be removed > in a subsequent bug to update the JDK copy of Graal with the upstream version > which > no longer uses the methods. The methods destined for removal are: > > exportJVMCITo(Class<?> requestor) > load(Class<S> service) > loadSingle(Class<S> service, boolean required) > > The first one is no longer needed as JVMCI exports itself to Graal service > providers > it loads via private API and Graal re-exports[1] JVMCI to any module the > extends Graal. > The latter 2 are no longer required as Graal uses the standard ServiceLoader. > This API > is only useful for JVMCI-8 where a hidden JVMCI class loader is used. > > These changes have been tested against upstream Graal. To make the Graal > tests pass, 2 extra > minor changes were required: > > 1. In JDK-8177673, HotSpotMemoryAccessProviderImpl::checkRead was added and > throws IllegalArgumentException > on all error paths except one which throws AssertionError. The latter was a > mistake and has been > fixed to also throw IllegalArgumentException. > 2. An invalid assertion has been removed from > HotSpotResolvedObjectTypeImpl::isDefinitelyResolvedWithRespectTo. > Up to JDK 8, it was true that all classes in java.* packages were loaded by > the boot class loader. > This is no longer true in JDK 9 with classes like java.sql being loaded by > platform class loader. > > As hinted above, a subsequent bug will be required to pull in the latest > upstream Graal and > remove use of JDK internal API from the jdk.aot module. The qualified exports > to > jdk.vm.internal.compiler and jdk.aot can then be removed. > > -Doug > > https://bugs.openjdk.java.net/browse/JDK-8177845 > http://cr.openjdk.java.net/~dnsimon/8177845/ > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess > > >