BackEnd Service Provider.

[Doug Simon]

Hi Gary,

> On 20 Apr 2020, at 14:44, Gary Frost <frost.gary at gmail.com> wrote:
> 
> Yeah I started created a module, but it seems for my module to compile I need jdk.internal.vm.ci <https://urldefense.com/v3/__http://jdk.internal.vm.ci__;!!GqivPVa7Brio!IQVX1iggkDspLlkVBXNQ7IulcpTkED_VhK6SjF2apyR4-XW-E7oZHqeQPPY4GJB0$> module to export org.graalvm.compiler.hotspot.HotSpotBackendFactory to my named module.  Which seems wrong. 

Actually, that’s by design. Only standard JDK API can be exported unqualified from the JDK. Neither Graal nor JVMCI is public API and so --add-exports is needed for compilation.

> 
> I wanted to avoid using GraalVM.  I figured I should be able to do what I want, using stock/released JDK13 and  -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler 

You can - you just need --add-exports (and maybe some other options) to “open up” the classes you’re trying to hook into.

> I can 'get around it' by pulling the source for org.graalvm.compiler.hotspot.CompilerConfigurationFactory locally.  Hacking this one file (to load my Factory) then building using using  --patch-module jdk.internal.vm.compiler=src/jdk.internal.vm.compiler/java, but this is clearly hacky. I should not have to use --patch-module here.
> 
> Alas using --patch-module renders IntelliJ next to useless (it ignores patch-module) as pointed out by  John Rose and myself here. 
> https://youtrack.jetbrains.com/issue/IDEA-224342 <https://urldefense.com/v3/__https://youtrack.jetbrains.com/issue/IDEA-224342__;!!GqivPVa7Brio!IQVX1iggkDspLlkVBXNQ7IulcpTkED_VhK6SjF2apyR4-XW-E7oZHqeQPKLKl6Nu$>
> 
> Maybe the intent was that the JDK versions of Graal, were just to 'use Graal', not to allow developers to add there own features.   
> 
> Maybe that is the distiction between GraalVM and Graal enabled JDK. 

No, both of these don’t not offer open extension points. You need to force it open on the command as mentioned above. We can’t have just any old app code getting their hands on the compiler ;-)

-Doug

> On Mon, Apr 20, 2020 at 11:54 AM Doug Simon <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> wrote:
> Hi Gary,
> 
> Have you tried creating a module for your service? I think that’s required as of JDK 9.
> 
> I suggest opening a PR on https://github.com/oracle/graal <https://urldefense.com/v3/__https://github.com/oracle/graal__;!!GqivPVa7Brio!IQVX1iggkDspLlkVBXNQ7IulcpTkED_VhK6SjF2apyR4-XW-E7oZHqeQPMQSQQsk$> so we can have a more concrete discussion.
> 
> -Doug
> 
> > On 20 Apr 2020, at 11:17, Gary Frost <frost.gary at gmail.com <mailto:frost.gary at gmail.com>> wrote:
> > 
> > I feel I am missing something obvious ;)
> > 
> > I am working (well playing actually) with Graal and JDK13 and have built my
> > own implementation of org.graalvm.compiler.hotspot.HotSpotBackendFactory to
> > inject some custom code into generated x86.  Very cool.
> > 
> > If I hack the org.graalvm.compiler.hotspot.CompilerConfigurationFactory
> > class (from JDK13 source) I can instantiate  my factory directly, and I see
> > my modified code.
> > 
> > But of course I want to able to build against and use use my factory using
> > a clean opendjdk JDK13 binary distribution.
> > 
> > It looks like the
> > class org.graalvm.compiler.hotspot.CompilerConfigurationFactory is setup to
> > allow me to offer my factory as a 'service provider' which the
> > CompilerConfigurationFactory accesses via this call
> >           GraalServices.load(HotSpotBackendFactory.class)
> > but nothing I try works.
> > 
> > It looks like I need to provide a module-info.java class, but of course I
> > only want my one service to override the default.
> > 
> > Any suggestions/help oir pointers to docs would be appreciated.
> > 
> > Gary
>