JVMCI 0.57 released

[David Lloyd]

On Tue, Mar 26, 2019 at 6:14 AM Gilles Duboscq
<gilles.m.duboscq at oracle.com> wrote:
>
> Hi David,
>
> I think the more interesting question here is around the things you are using (e.g., `GraalFeature`) that in turn make you need to depend on JVMCI.
> The reason why it's not easy to consume at the moment is that none of this (classes in `com.oracle.svm.core` and others) is API.
>
> The only APIs available at the moment for interaction with SVM are the classes in `org.graalvm.nativeimage` which are part of the the Graal SDK.
> This is available on maven as `org.graalvm.sdk:graal-sdk`.
>
> Since you are using things from `com.oracle.svm.core.graal`, i'm guessing you didn't find the APIs you need in the SDK.
> Could you describe your use-case in more detail? Maybe then we could then see if there is a way we can improve/extend the API in the SDK to fit your use-case.

Basically I want to pilot a few possible optimizations outside of the
SubstrateVM tree, some of which might be very specific to a particular
library.  Some of these might end up as upstream feature requests or
PRs to SubstrateVM, and some might just end up getting discarded.  But
regardless, any manipulation of the compile tree is not possible
without the more specific `GraalFeature` API AFAICT.

I'm not too worried about breaking changes because we're presently
mandating specific SubstrateVM version(s) to be used with the Quarkus
project.  But, I don't really want to force people to use GraalVM or
the Labs SDK to *build* Quarkus as it might really discourage outside
development/contribution.
-- 
- DML