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