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

Jaroslav Tulach jaroslav.tulach at oracle.com
Thu Apr 23 12:00:41 UTC 2020


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 <doug.simon at oracle.com> 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 <Alan.Bateman at oracle.com> 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






More information about the jigsaw-dev mailing list