JVMCI 0.57 released

[Doug Simon]

> On 25 Mar 2019, at 16:05, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> On Sun, Mar 24, 2019 at 1:42 PM Doug Simon <doug.simon at oracle.com <mailto:doug.simon at oracle.com>> wrote:
>> On 24 Mar 2019, at 19:19, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>> 
>> My use case is including a specialized GraalVM feature in an artifact,
>> the API of which relies on JVMCI classes.  The feature would only be
>> used when using the SubstrateVM native image compiler, otherwise the
>> classes would remain unused.  I'm hesitant to require using the JVMCI
>> or GraalVM JDK to build the project; the only alternative I can think
>> of would be an external artifact with the classes in it.
>> 
>> 
>> Maybe you can expand on this hesitation a bit. I’m not sure how you can use this feature without an actual JVMCI implementation underneath. Are you able to sketch out a simplified picture of the feature?
> 
> Sorry I meant literally the `GraalFeature` API within the GraalVM
> project.  This allows an artifact within a native image compilation to
> sort of "hack in" to the compilation process to do various things like
> specialized optimizations.  But, it relies on the JVMCI API so you
> can't generally compile such classes without it.

This seems like a discussion that should involve the native image team if there is some artifact available via Maven that has a JVMCI dependency. Paul, how would you suggest David can proceed with developing against com.oracle.svm.core.graal.GraalFeature in terms of satisfying the JVMCI dependency? Is there maybe an alternative way to achieve this that doesn’t involve having to resolve JVMCI for compilation?

-Doug

> 
> But the classes are only used when a native image is being generated
> and aren't otherwise loaded, so the artifact can still work fine in a
> regular JVM.  So it would be nice to be able to compile against these
> classes without them being present in the JDK being used for
> compilation.
> 
>> 
>> -Doug
>> 
>> 
>> On Sun, Mar 24, 2019 at 5:19 AM Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> 
>> Hi David,
>> 
>> On 23 Mar 2019, at 15:59, David Lloyd <david.lloyd at redhat.com> wrote:
>> 
>> Is there any possibility of the JVMCI API classes being released as a
>> Maven artifact?  It would allow development of software which can
>> optionally consume JVMCI without requiring a JVMCI JDK for building.
>> 
>> 
>> I suspect that is a very small software niche. Graal is the only consumer of JVMCI I’m currently aware of and it makes very little sense to develop Graal without a JVMCI JDK.
>> 
>> Note also that there is not just one current JVMCI version but potentially one per JDK version that Graal supports. Graal can (and does) use differing JVMCI API using versioned sources (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_mx-23versioning-2Dsources-2Dfor-2Ddifferent-2Djdk-2Dreleases&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=ftfZhJgS3d2iQ_0_mpAIneaYGlfExJ1WNxONRCAlaOk&s=JR_oMGVUidDKax3Z8LCC_1_Z15YAlraGkWTHTEKuDMU&e=). For example, the new HotSPOTJVMCIRuntime.excludeFromJVMCICompilation method added in jvmci-0.57 is used from JVMCI JDK8 specific code.
>> 
>> What would a compelling use case be for developing against JVMCI without actually executing the artifact?
>> 
>> -Doug
>> 
>> 
>> On Fri, Mar 22, 2019 at 4:47 PM Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> 
>> Changes in JVMCI 0.57 include:
>> 
>> • GR-13902: Replace adjustCompilationLevel mechanism.
>> • GR-14526: Replace JVMCINMethodData constructor and operator new with initialize.
>> • GR-14509: Fixed order of method mirror invalidation.
>> • GR-14475: Fix support for jvmci.InitTimer.
>> • GR-14105: Remove uses of system properties.
>> 
>> The GR-13902 change introduced new API for implementing -Dgraal.CompileGraalWithC1Only=true without requiring a Java up-call from the VM when scheduling a method for compilation. This fixes a number of subtle bugs and unexpected VM behavior (see https://bugs.openjdk.java.net/browse/JDK-8219403). As a result of the API change, you need to update Graal to commit b3ec4830e02 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_commit_b3ec4830e0295561bde16740b35efd0bbc4cfccf&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=ZXOFIL3cRL2FIe2PYoKmuGRJYgPnkR05P1BNCwV6zeo&s=nZKyMkxCPpDHBF_tfvFkz-N4MF9QNYQsj5aUzT-CrEU&e=> or later when using this JVMCI release.
>> 
>> The OpenJDK based binaries are at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_graalvm_openjdk8-2Djvmci-2Dbuilder_releases_tag_jvmci-2D0.57&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=ZXOFIL3cRL2FIe2PYoKmuGRJYgPnkR05P1BNCwV6zeo&s=jnieBzEva0XUzWqVXNZ2O1DmNRW1FW-w6FE3HPAp1fk&e=
>> 
>> The OracleJDK based “labsjdk” binaries will be available soon at https://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html (in the lower half of the page).
>> 
>> -Doug
>> 
>> 
>> 
>> 
>> --
>> - DML
>> 
>> 
>> 
>> 
>> --
>> - DML
>> 
>> 
> 
> 
> -- 
> - DML