Problem loading Truffle service providers in Graal

[Doug Simon]

> On 26 Feb 2017, at 13:26, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 26 Feb 2017, at 13:22, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On 26 Feb 2017, at 13:08, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 26/02/2017 11:20, Doug Simon wrote:
>>> 
>>>> While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are:
>>>> 
>>>> module com.oracle.truffle.truffle_api {
>>>> 
>>>>   exports com.oracle.truffle.object;
>>>>   exports com.oracle.truffle.object.basic;
>>>> 
>>>>   uses com.oracle.truffle.api.object.LayoutFactory;
>>>>   provides com.oracle.truffle.api.object.LayoutFactory with com.oracle.truffle.object.basic.DefaultLayoutFactory;
>>>> 
>>>> }
>>>> 
>>>> module jdk.internal.vm.compiler {
>>>>        requires transitive com.oracle.truffle.truffle_api;
>>>>   uses com.oracle.truffle.api.object.LayoutFactory;
>>>> 
>>>> }
>>>> 
>>>> However, looking up a provider in Graal[1] returns no providers. As far as I understand service loading with modules, this is  because jdk.internal.vm.compiler is loaded via the platform class loader while truffle is loaded via the app class loader as shown by the output of trace statements I added:
>>>> 
>>>> GraalTruffleRuntime.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 366e2eef
>>>> LayoutFactory.class.getClassLoader() -> jdk.internal.loader.ClassLoaders$AppClassLoader at 6df97b55
>>>> 
>>>> This ability of a platform loaded class to depend on an app loaded class is probably due to the soon-to-be-disabled mechanism[2] we use for overriding the version of Graal bundled with JDK 9.
>>>> 
>>>> Is there some command line magic I can use to make this case work now or do I have to wait until [2] is addressed? If the latter, how will it work then?
>>>> 
>>> An upgraded moduledefined to the platform loader can link to types in modules defined to the app loader. So I wouldn't expect issues there.
>>> 
>>> Can you track down the code that uses ServiceLoader.load to load the LayoutFactory providers?
>> 
>> The code is in the first link of my previous message:
>> 
>> https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693
>> 
>>> It might be using loadInstalled or invoking it with the platform class loader and that would explain what you are seeing.
>> 
>> Thanks - using LayoutFactory.class.getClassLoader() works. So the general rule is to use the leaf most class loader the service client knows about?
> 
> If that's the case, does that mean I could pick up any provider on the app class path? Seems a little risky. Is there some way to confine it to modules the service user trusts (by virtual of being a module in its dependency graph)?

Also, what if there's provider in jdk.internal.vm.compiler itself? Will it be loaded along with the providers on my module path?

-Doug