[graalvm-dev] Formal dependency on JVMCI

Doug Simon doug.simon at oracle.com
Mon Sep 30 05:33:29 PDT 2019



> On 30 Sep 2019, at 13:41, Chris Seaton <chris.seaton at shopify.com> wrote:
> 
> 
> 
> 
>> On 30 Sep 2019, at 12:34, Doug Simon <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> wrote:
>> 
>> Hi Chris,
>> 
>> The source truth for the required JVMCI version is in JVMCIVersionCheck.java <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_03217a31ee2f8e3fb2b75e9d7b14220d645e5955_compiler_src_org.graalvm.compiler.hotspot_src_org_graalvm_compiler_hotspot_JVMCIVersionCheck.java&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=V9XGD9ImMM__PcFglow66ZxckB3qs-u61Be_7TLx-p8&s=QIwQq5Q_hlUyWJImY8ZhmQ7agiRSeznDCIE_NOqComE&e=>.
> 
> Ok I’ll use that as my single source of truth, thanks.
> 
> How come it doesn’t match what’s used in CI, though? The third digit is the build, right? This shows b2 and b3 being used in the same commit.

Because JVMCIVersionCheck specifies the *minimum* JVMCI version from an API perspective. Later JVMCI release can contain performance or bug fixes. As such, we bump JVMCI import more often in CI than we update JVMCIVersionCheck.

> 
> https://github.com/oracle/graal/blob/1d9d33960b860a97fa3c488789f007f1229cc390/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/JVMCIVersionCheck.java <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_1d9d33960b860a97fa3c488789f007f1229cc390_compiler_src_org.graalvm.compiler.hotspot_src_org_graalvm_compiler_hotspot_JVMCIVersionCheck.java&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=V9XGD9ImMM__PcFglow66ZxckB3qs-u61Be_7TLx-p8&s=hl2nDah7mmMMB5NRwLxu_986d4B2Bjy-DFFUG1xiqCw&e=>
> https://github.com/oracle/graal/blob/1d9d33960b860a97fa3c488789f007f1229cc390/common.hocon#L10 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_1d9d33960b860a97fa3c488789f007f1229cc390_common.hocon-23L10&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=V9XGD9ImMM__PcFglow66ZxckB3qs-u61Be_7TLx-p8&s=KMg-a_6NwOUf-V3GUlito4gy35TOL6tpeGNpt9K3XBs&e=>
>> Where else and in what format would you like that to be declared? Note that with JDK 11 about to be supported, a single JVMCI version number will denote 2 different base JDKs.
> 
> All other version dependency information is in the chain of suite.py files. JVMC is I think the only exception, so seems like it should be in there instead, and perhaps JVMCIVersionCheck.java built from it during compilation?

Suite.py is used for declaring *exact* versioned dependencies. As stated above, JVMCIVersionCheck is not an exact version dependency.

> Ultimately, the fact that the JVMCI version is repeated tens of times all over the code base (lots of CI files, that Java file, etc), and that it’s being scraped with regular expressions from these files, gives me the idea that something about how it is being declared is not right.

I agree that it’s not optimal. We have an internal issue for making JVMCI JDK dependency be like all other dependencies so I think we’ll have it in suite.py before long.

-Doug

> 
>> -Doug
>> 
>>> On 30 Sep 2019, at 12:48, Chris Seaton <chris.seaton at shopify.com <mailto:chris.seaton at shopify.com>> wrote:
>>> 
>>> Could we get some kind of declarative dependency on a JVMCI version from GraalVM and languages? As I understand it, Graal depends on a particular JVMCI version. But which version? I have to go scraping around to figure it out from clues like the CI configuration when I do my own builds.
>>> 
>>> Would it make sense to declare a clear dependency on a JVMCI version in our mx suites like we do on other components?
>>> 
>>> Examples of issues this causes includes the number of places it’s repeated and the various formats it’s in.
>>> 
>>> https://github.com/oracle/graal/commit/d8f623a1957ee378c4d20cefabc0950878037620 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_commit_d8f623a1957ee378c4d20cefabc0950878037620&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=P1aEbpQqX18a0ssutGCeizsWEVvvJcWvSeSxdI9X3-o&m=5Fpxezl2ceVCO_hT1GeSBkUl-njbxmg2gJsRbxLRrWM&s=T6fWXJ_7oIW8j_KkbxC15oEaErQ4X6Yr5WUYSQKr1YU&e=>
>>> https://github.com/oracle/truffleruby/commit/0808ffc9e65a98c38a252c87f917e34cff584b28 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_truffleruby_commit_0808ffc9e65a98c38a252c87f917e34cff584b28&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=P1aEbpQqX18a0ssutGCeizsWEVvvJcWvSeSxdI9X3-o&m=5Fpxezl2ceVCO_hT1GeSBkUl-njbxmg2gJsRbxLRrWM&s=G6Pm_bwKdM6pZmGIE65bZS7t_9-Geuwr9mCflnmfgww&e=>
>>> https://github.com/oracle/truffleruby/commit/e79e9d57d665bd15d77d80c0b53b547bd0eeff73 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_truffleruby_commit_e79e9d57d665bd15d77d80c0b53b547bd0eeff73&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=P1aEbpQqX18a0ssutGCeizsWEVvvJcWvSeSxdI9X3-o&m=5Fpxezl2ceVCO_hT1GeSBkUl-njbxmg2gJsRbxLRrWM&s=ijCPXws2Igq6u0uayVUxHLoKXHNzG0soxwFdX_D6ziA&e=>
>>> 
>>> Regards,
>>> 
>>> Chris
>>> _______________________________________________
>>> GraalVM-Dev mailing list
>>> GraalVM-Dev at oss.oracle.com <mailto:GraalVM-Dev at oss.oracle.com>
>>> https://oss.oracle.com/mailman/listinfo/graalvm-dev <https://oss.oracle.com/mailman/listinfo/graalvm-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-dev/attachments/20190930/2e648bba/attachment.html 


More information about the GraalVM-Dev mailing list