> On 19 Apr 2017, at 22:29, Vladimir Kozlov <vladimir.koz...@oracle.com> wrote:
>
> ReflectionAccessJDK ? Based on your comment in the file.
>
> Vladimir
>
> 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.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
>>>>
>>>>
>>>>
>>
