Re: BackEnd Service Provider.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: BackEnd Service Provider.

Alan Bateman
On 21/04/2020 14:01, Doug Simon wrote:
> Hi Gary,
>
> I cannot understand why --add-reads does not work and have reached out
> to Alan Bateman for more insight.
>
I read through the thread [1] and I don't see an obvious solution to this.

The main issue here is that org.grfstuff.compiler wants to provide an
implementation of org.graalvm.compiler.hotspot.HotSpotBackendFactory but
that service type is not in org.grfstuff.compiler and
org.graalvm.compiler.hotspot is not exported to org.grfstuff.compiler by
any of the modules that it reads. The post resolution consistency check
that it trips up on is specified in the Configuration API docs if you
are interested.

I assume `--add-exports
jdk.internal.vm.compiler/org.graalvm.compiler.hotspot=org.grfstuff.compiler`
was added in an attempt to workaround this but that CLI option is the
equivalent of jdk.internal.vm.compiler invoking Module::addExports after
the module graph has been reified. It doesn't impact resolution or any
of the post resolution consistency checks at run-time. Yes, there is an
unfortunate difference between between compile-time and run-time in this
regard but that is something for another discussion.

I don't think there are any obvious workarounds. The Module API defines
addXXX methods to export or open packages at run-time, extend
readability or add a service dependences but it doesn't define
addProvides. I think it came up once during JDK 9 but more in the
context of symmetry rather than a compelling use-case. It's not clear
that the issue under discussion here is compelling enough, needs more
thought as the scenario is a bit weird. If org.grfstuff.compiler was co
developed with jdk.internal.vm.compiler then it could use a qualified
export of course.

Initially I thought you could workaround this by moving
org.grfstuff.compiler  to the class path but this it's not going to work
as ServiceLodaer usage in Graal seems to use module layers as congtext,
so it will not find implementations on the class path.

-Alan

[1] https://mail.openjdk.java.net/pipermail/graal-dev/2020-April/005949.html
Reply | Threaded
Open this post in threaded view
|

Re: BackEnd Service Provider.

Doug Simon
Thanks for your valuable input Alan.

So until the VM provides an --add-provides option (which is not currently planned), --patch-module is the only mechanism for dynamically adding providers of otherwise “sealed” Graal services. We could indeed make Graal service loading look for providers on the class path but that would have to be off by default and thus require a command line option (e.g. -Dgraal.AllowServicesOnClassPath=true). However, that doesn’t seem like any less effort than having to use --patch-module.

-Doug

> On 22 Apr 2020, at 09:12, Alan Bateman <[hidden email]> wrote:
>
> On 21/04/2020 14:01, Doug Simon wrote:
>> Hi Gary,
>>
>> I cannot understand why --add-reads does not work and have reached out to Alan Bateman for more insight.
>>
> I read through the thread [1] and I don't see an obvious solution to this.
>
> The main issue here is that org.grfstuff.compiler wants to provide an implementation of org.graalvm.compiler.hotspot.HotSpotBackendFactory but that service type is not in org.grfstuff.compiler and org.graalvm.compiler.hotspot is not exported to org.grfstuff.compiler by any of the modules that it reads. The post resolution consistency check that it trips up on is specified in the Configuration API docs if you are interested.
>
> I assume `--add-exports jdk.internal.vm.compiler/org.graalvm.compiler.hotspot=org.grfstuff.compiler` was added in an attempt to workaround this but that CLI option is the equivalent of jdk.internal.vm.compiler invoking Module::addExports after the module graph has been reified. It doesn't impact resolution or any of the post resolution consistency checks at run-time. Yes, there is an unfortunate difference between between compile-time and run-time in this regard but that is something for another discussion.
>
> I don't think there are any obvious workarounds. The Module API defines addXXX methods to export or open packages at run-time, extend readability or add a service dependences but it doesn't define addProvides. I think it came up once during JDK 9 but more in the context of symmetry rather than a compelling use-case. It's not clear that the issue under discussion here is compelling enough, needs more thought as the scenario is a bit weird. If org.grfstuff.compiler was co developed with jdk.internal.vm.compiler then it could use a qualified export of course.
>
> Initially I thought you could workaround this by moving org.grfstuff.compiler  to the class path but this it's not going to work as ServiceLodaer usage in Graal seems to use module layers as congtext, so it will not find implementations on the class path.
>
> -Alan
>
> [1] https://mail.openjdk.java.net/pipermail/graal-dev/2020-April/005949.html

Reply | Threaded
Open this post in threaded view
|

Debugging your Graal Compiler Extensions with GraalVM's IGV was: BackEnd Service Provider.

Jaroslav Tulach
Hello Gary.
Here is a pull request that turns the project structure into a set of three
Maven modules:

https://github.com/grfrost/graal_service_issue/pull/1

As Maven is more approachable to common Java IDEs, one can use for example
GraalVM's Ideal Graph Visualizer to edit, compile, run & debug the project.
See the pull request for detailed instructions.

Best regards.
Jaroslav Tulach
NetBeans Platform Architect
OracleLabs

Dne středa 22. dubna 2020 11:16:22 CEST, Gary Frost napsal(a):

> Thanks for both looking  into this
>
> I have an IntelliJ workaround that sort of works (I will pass on to John
> Rose, because he reported the same issue to IntelliJ), which is obvious in
> hindsight.  I launch outside of IDE using --patch-module and get the
> process to wait, then attach from IDE. This gets around issue of IDE not
> honouring --patch-module.  So I can at least debug in IDE.
>
> Just some more feedback on misspent hours ;)
>
> I actually modified JDK13 to allow me to pass in a property (name of
> factory implementing org.graalvm.compiler.hotspot.HotSpotBackendFactory)
> and built. Then of course the issues was that my factory was not in the
> classpath ;)  I tried creating a classloader seeded via  a jar name (via
> another property) but it all went downhill fairly fast...  after that...
> curses were shouted... dogs were kicked and beer was consumed.
>
> So clearly --patch-module not only allows replacing 'system' classes, it
> allows all the other classes in the patched path, to be treated as if they
> were on system classpath, ala ye olde -Xbootclasspath.
>
> Anyway again, thanks for having a look, and possibly keeping this type of
> usecase in mind was we try to allow access to graal.  It would be nice to
> make this easy for folk.
>
> PS. No dogs were really harmed, during the classloading hacking.
>
> Gary
>
> On Wed, Apr 22, 2020 at 8:31 AM Doug Simon <[hidden email]> wrote:
> > Thanks for your valuable input Alan.
> >
> > So until the VM provides an --add-provides option (which is not currently
> > planned), --patch-module is the only mechanism for dynamically adding
> > providers of otherwise “sealed” Graal services. We could indeed make Graal
> > service loading look for providers on the class path but that would have
> > to
> > be off by default and thus require a command line option (e.g.
> > -Dgraal.AllowServicesOnClassPath=true). However, that doesn’t seem like
> > any
> > less effort than having to use --patch-module.
> >
> > -Doug
> >
> > > On 22 Apr 2020, at 09:12, Alan Bateman <[hidden email]> wrote:
> > >
> > > On 21/04/2020 14:01, Doug Simon wrote:
> > >> Hi Gary,
> > >>
> > >> I cannot understand why --add-reads does not work and have reached out
> >
> > to Alan Bateman for more insight.
> >
> > > I read through the thread [1] and I don't see an obvious solution to
> >
> > this.
> >
> > > The main issue here is that org.grfstuff.compiler wants to provide an
> >
> > implementation of org.graalvm.compiler.hotspot.HotSpotBackendFactory but
> > that service type is not in org.grfstuff.compiler and
> > org.graalvm.compiler.hotspot is not exported to org.grfstuff.compiler by
> > any of the modules that it reads. The post resolution consistency check
> > that it trips up on is specified in the Configuration API docs if you are
> > interested.
> >
> > > I assume `--add-exports
> >
> > jdk.internal.vm.compiler/org.graalvm.compiler.hotspot=org.grfstuff.compile
> > r` was added in an attempt to workaround this but that CLI option is the
> > equivalent of jdk.internal.vm.compiler invoking Module::addExports after
> > the module graph has been reified. It doesn't impact resolution or any of
> > the post resolution consistency checks at run-time. Yes, there is an
> > unfortunate difference between between compile-time and run-time in this
> > regard but that is something for another discussion.
> >
> > > I don't think there are any obvious workarounds. The Module API defines
> >
> > addXXX methods to export or open packages at run-time, extend readability
> > or add a service dependences but it doesn't define addProvides. I think it
> > came up once during JDK 9 but more in the context of symmetry rather than
> > a
> > compelling use-case. It's not clear that the issue under discussion here
> > is
> > compelling enough, needs more thought as the scenario is a bit weird. If
> > org.grfstuff.compiler was co developed with jdk.internal.vm.compiler then
> > it could use a qualified export of course.
> >
> > > Initially I thought you could workaround this by moving
> >
> > org.grfstuff.compiler  to the class path but this it's not going to work
> > as
> > ServiceLodaer usage in Graal seems to use module layers as congtext, so it
> > will not find implementations on the class path.
> >
> > > -Alan
> > >
> > > [1]
> >
> > https://mail.openjdk.java.net/pipermail/graal-dev/2020-April/005949.html