Graal and JDK11

[Remi Forax]

Hi Bob, hi Doug,
at some point you will have to decide what to do with ldc on a ConstantDynamic [1],
i believe it should work a lot like a constant initialized in a static block.
i.e. the bootstrap method is run when creating the image and all ldc on that ConstantDynamic should be replaced by the result of the bootstrap call.  

Rémi

[1] https://openjdk.java.net/jeps/309

----- Mail original -----
> De: "Doug Simon" <doug.simon at oracle.com>
> À: "Bob McWhirter" <bmcwhirt at redhat.com>
> Cc: "Paul Wögerer" <paul.woegerer at oracle.com>, "graal-dev" <graal-dev at openjdk.java.net>
> Envoyé: Jeudi 18 Avril 2019 23:16:47
> Objet: Re: Graal and JDK11

> Hi Bob,
> 
> Thanks for this effort!
> 
> The next steps will be to convert some of these jars into modules and add them
> to the JRT image. Then the native-image launcher (i.e. NativeImage class) will
> have to be modified to add all the module options to the inner VM command that
> runs the NativeImageGenerator. I’m sure there’s other pieces as well.
> 
> Once we emerge from the current stabilization period (in about a month), someone
> (probably Danilo or Paul) will follow up with you on how we can proceed.
> 
> -Doug
> 
>> On 18 Apr 2019, at 19:29, Bob McWhirter <bmcwhirt at redhat.com> wrote:
>> 
>> Through a series of hacks, I've been able to create a `native-image` binary
>> based on JDK, and then use it to produce a simple binary native-image from
>> a Hello World application.
>> 
>> Unlike JDK8-based, I have to pass a significant amount of `-cp` and
>> `--module-path` arguments to the `native-image` CLI.
>> 
>> ./latest_graalvm_home/lib/svm/bin/native-image \
>>  -cp
>> ~/iron/test:/Users/bob/repos/graal/sdk/mxbuild/dists/jdk11/graal-sdk.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk1.8/objectfile.jar:/Users/bob/repos/graal/truffle/mxbuild/dists/jdk11/truffle-api.jar:/Users/bob/repos/graal/compiler/mxbuild/dists/jdk11/graal.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk1.8/pointsto.jar:/Users/bob/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest.jar:/Users/bob/.mx/cache/JUNIT_2973d150c0dc1fefe998f834810d68f278ea58ec/junit.jar:/Users/bob/repos/protean/mx/mxbuild/dists/jdk1.8/junit-tool.jar:/Users/bob/repos/graal/truffle/mxbuild/dists/jdk11/truffle-nfi.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk9/svm.jar:/Users/bob/.mx/cache/JLINE_c3aeac59c022bdc497c8c48ed86fa50450e4896a/jline.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk1.8/library-support.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk1.8/svm-driver.jar:/Users/bob/repos/graal/substratevm/mxbuild/dists/jdk1.8/svm-agent.jar
>> \
>>  Foo \
>> 
>> -J--module-path=/Users/bob/repos/graal/vm11/mxbuild/darwin-amd64/GRAALVM_CMP_GU_GVM_NFI_POLYNATIVE_RGX_STAGE1_SVM_SVMAG_SVMCF_SVML_TFL/graalvm-unknown-1.0.0-rc15-dev/Contents/Home/lib/svm/bin/../../boot/graal-sdk.jar:/Users/bob/repos/graal/vm11/mxbuild/darwin-amd64/GRAALVM_CMP_GU_GVM_NFI_POLYNATIVE_RGX_STAGE1_SVM_SVMAG_SVMCF_SVML_TFL/graalvm-unknown-1.0.0-rc15-dev/Contents/Home/lib/svm/bin/../../truffle/truffle-api.jar\
>> 
>> -J--upgrade-module-path=/Users/bob/repos/graal/vm11/mxbuild/darwin-amd64/GRAALVM_CMP_GU_GVM_NFI_POLYNATIVE_RGX_STAGE1_SVM_SVMAG_SVMCF_SVML_TFL/graalvm-unknown-1.0.0-rc15-dev/Contents/Home/lib/svm/bin/../../jvmci/graal.jar:/Users/bob/repos/graal/vm11/mxbuild/darwin-amd64/GRAALVM_CMP_GU_GVM_NFI_POLYNATIVE_RGX_STAGE1_SVM_SVMAG_SVMCF_SVML_TFL/graalvm-unknown-1.0.0-rc15-dev/Contents/Home/lib/svm/bin/../../jvmci/graal-management.jar
>> \
>>  -J--add-opens=org.graalvm.truffle/com.oracle.truffle.polyglot=ALL-UNNAMED
>> \
>>  -J--add-opens=org.graalvm.truffle/com.oracle.truffle.api.impl=ALL-UNNAMED
>> \
>> 
>> -J--add-opens=jdk.internal.vm.compiler/org.graalvm.compiler.debug=ALL-UNNAMED
>> \
>>  -J--add-opens=org.graalvm.sdk/org.graalvm.polyglot=ALL-UNNAMED \
>>  -H:Name=foo \
>>  --no-server \
>>  -H:+ReportExceptionStackTraces
>> 
>> The resulting binary works as you'd expect for a simplistic app:
>> 
>> $ ./foo
>> Hello world from Java 11.0.1
>> $ du -sh ./foo
>> 13M ./foo
>> $ file ./foo
>> ./foo: Mach-O 64-bit executable x86_64
>> 
>> 
>> Thus far I've mostly be faffing about to figure out what's needed.
>> 
>> Does anything have any insight on how to bake this stuff into the basic
>> execution of native-image, preferably storing all the module-path and such
>> inside the native-image binary itself, instead of having to reference
>> outboard modules/jars/etc?
>> 
>> Apologies if there's a better place/way to discuss this.
>> 
>> Thanks,
>> 
>> Bob McWhirter
> > Red Hat