Re: Problem loading Truffle service providers in Graal

[Doug Simon]

> On 26 Feb 2017, at 14:44, Alan Bateman  wrote:
> 
> 
> 
> On 26/02/2017 13:13, Doug Simon wrote:
>> :
>> Also, what if there's provider in jdk.internal.vm.compiler itself? Will it 
>> be loaded along with the providers on my module path?
>> 
> If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it will 
> be located too.

I assume that's because the app class loader delegates to the platform class 
loader?

> If the provider interface is only for overriding then you could use 
> ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get())
>  so that it use a default/fallback implementation in your module when there 
> isn't a provider deployed on the module path.

Ok, thanks for the tip.

-Doug

Re: Problem loading Truffle service providers in Graal

[Alan Bateman]

On 26/02/2017 13:13, Doug Simon wrote:

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

If it has `provides com.oracle.truffle.api.object.LayoutFactory` then it 
will be located too. If the provider interface is only for overriding 
then you could use 
ServiceLoader.load(LayerFactory.class).findFirst().orElse(DefaultLayoutFactory.get()) 
so that it use a default/fallback implementation in your module when 
there isn't a provider deployed on the module path.


-Alan

Re: Problem loading Truffle service providers in Graal

[Alan Bateman]

On 26/02/2017 12:26, Doug Simon wrote:


:
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)?


You can restrict the service type using a qualified export.

-Alan

Re: Problem loading Truffle service providers in Graal

[Doug Simon]

> On 26 Feb 2017, at 13:26, Doug Simon  wrote:
> 
>> 
>> On 26 Feb 2017, at 13:22, Doug Simon  wrote:
>> 
>>> 
>>> On 26 Feb 2017, at 13:08, Alan Bateman  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@366e2eef
 LayoutFactory.class.getClassLoader() -> 
 jdk.internal.loader.ClassLoaders$AppClassLoader@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

Re: Problem loading Truffle service providers in Graal

[Doug Simon]

> On 26 Feb 2017, at 13:22, Doug Simon  wrote:
> 
>> 
>> On 26 Feb 2017, at 13:08, Alan Bateman  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@366e2eef
>>> LayoutFactory.class.getClassLoader() -> 
>>> jdk.internal.loader.ClassLoaders$AppClassLoader@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)?

-Doug

Re: Problem loading Truffle service providers in Graal

[Doug Simon]

> On 26 Feb 2017, at 13:08, Alan Bateman  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@366e2eef
>> LayoutFactory.class.getClassLoader() -> 
>> jdk.internal.loader.ClassLoaders$AppClassLoader@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?

-Doug

Re: Problem loading Truffle service providers in Graal

[Alan Bateman]

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@366e2eef
LayoutFactory.class.getClassLoader() -> 
jdk.internal.loader.ClassLoaders$AppClassLoader@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? It might be using loadInstalled or invoking it 
with the platform class loader and that would explain what you are seeing.


-Alan

Problem loading Truffle service providers in Graal

[Doug Simon]

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@366e2eef
LayoutFactory.class.getClassLoader() -> 
jdk.internal.loader.ClassLoaders$AppClassLoader@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?

-Doug

[1] 
https://github.com/graalvm/graal-core/blob/1efc1c543acd7ed447c59788aeabc223be13e774/graal/org.graalvm.compiler.truffle/src/org/graalvm/compiler/truffle/GraalTruffleRuntime.java#L693
[2] http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html