Sure - how about good old Util? ;-) I'm open to other suggestions. Sent from my iPhone
> On Apr 19, 2017, at 9:46 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> > wrote: > > 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 >> >> >>
