Hi Doug,
Can you consider using other name and not JDK9 for new JVMCI class? It
will be used in JDK 10 too:
jdk.vm.ci.services.internal.JDK9;
Thanks,
Vladimir
On 4/18/17 3:13 PM, Doug Simon wrote:
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-8177663, 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
