> 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
>>>
>>>
>>>
>>
>
