RFR: 8177845: Need a mechanism to load Graal

[Christian Thalinger]

> On Apr 19, 2017, at 8:38 AM, Mandy Chung <mandy.chung at 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 <cthalinger at 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.simon at 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
>>> 
>>> 
>>> 
>> 
>