> On Apr 19, 2017, at 8:38 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > Since jdk.internal.vm.compiler becomes an upgradeable module, it is not > hashed with java.base to allow it to be upgraded and there is no integrity > check. Such qualified export will be granted to any module named > jdk.internal.vm.compiler at runtime. The goal is for upgradeable modules not > to use any internal APIs and eliminate the qualified exports. > > The main thing is that jdk.vm.ci.services API would need to be guarded if > it’s used by non-Graal modules.
This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. > > Mandy > >> On Apr 19, 2017, at 11:24 AM, Christian Thalinger <cthalin...@twitter.com> >> wrote: >> >> 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 >>> >>> >>> >> >