RFR: 8177845: Need a mechanism to load Graal
vladimir.kozlov at oracle.com
Wed Apr 19 20:29:24 UTC 2017
ReflectionAccessJDK ? Based on your comment in the file.
On 4/19/17 1:02 PM, Doug Simon wrote:
> 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.kozlov at 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:
>>> 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 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.
>>>  http://openjdk.java.net/projects/jigsaw/spec/issues/#IndirectQualifiedReflectiveAccess
More information about the hotspot-dev