From jackson at jcdav.is Fri Dec 1 08:04:47 2017 From: jackson at jcdav.is (Jackson Davis) Date: Fri, 1 Dec 2017 00:04:47 -0800 Subject: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE Message-ID: One afternoon over Thanksgiving break I hacked together a very basic fuzzer for JVM JITs (https://github.com/jcdavis/kabur/) which much to my surprise actually managed to find an issue in Graal :) This minimal test case reliably crashes the JVM from an unhandled SIGFPE: public class Crasher { public static int crash(int n, int d) { return n/(d|1); } public static void main(String[] args) { for(int i = 0; i < 100000; i++) { crash(i, i+1); } crash(Integer.MIN_VALUE, -1); } } Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) The source of this issue appears to be that IntegerDivRemNode.canDeoptimize only checks whether or not the denominator can be 0, not whether it can also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know what to do and dies. Adding the -1 check seems to make this to work as intended (AFAICT). I have a PR for a basic fix here: https://github.com/graalvm/graal/pull/266 Unfortunately this check breaks CountedLoopTest in a non-obvious way, which is where I am out of my depth. It seems the test's CheckGraphPhase introduces a SignedDivNode, however since this runs after FrameStateAssignmentPhase, there is no frame data, so an assert fails in the lowering. This seems to be fundamentally broken regardless of my change, but only started failing here since the denominator has as stamp of (-65536,-1) -Jackson From jackson at jcdav.is Fri Dec 1 08:17:45 2017 From: jackson at jcdav.is (Jackson Davis) Date: Fri, 1 Dec 2017 00:17:45 -0800 Subject: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE In-Reply-To: References: Message-ID: I should add that this "fix" is based on the idea that letting the idiv throw the SIGFPE is, in fact, the desired / expected behavior here. C2 handles this case by adding guards. -Jackson On Fri, Dec 1, 2017 at 12:04 AM, Jackson Davis wrote: > One afternoon over Thanksgiving break I hacked together a very basic > fuzzer for JVM JITs (https://github.com/jcdavis/kabur/) which much to my > surprise actually managed to find an issue in Graal :) > This minimal test case reliably crashes the JVM from an unhandled SIGFPE: > > public class Crasher { > public static int crash(int n, int d) { > return n/(d|1); > } > public static void main(String[] args) { > for(int i = 0; i < 100000; i++) { > crash(i, i+1); > } > crash(Integer.MIN_VALUE, -1); > } > } > Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation > -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) > > The source of this issue appears to be that IntegerDivRemNode.canDeoptimize > only checks whether or not the denominator can be 0, not whether it can > also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt > info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know > what to do and dies. Adding the -1 check seems to make this to work as > intended (AFAICT). I have a PR for a basic fix here: > https://github.com/graalvm/graal/pull/266 > > Unfortunately this check breaks CountedLoopTest in a non-obvious way, > which is where I am out of my depth. It seems the test's CheckGraphPhase > introduces a SignedDivNode, however since this runs after > FrameStateAssignmentPhase, there is no frame data, so an assert fails in > the lowering. This seems to be fundamentally broken regardless of my > change, but only started failing here since the denominator has as stamp of > (-65536,-1) > > -Jackson > > > From doug.simon at oracle.com Fri Dec 1 11:09:55 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Dec 2017 12:09:55 +0100 Subject: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE In-Reply-To: References: Message-ID: <7EF3FDBC-ABFD-4A20-B2AA-A0F308BABBE9@oracle.com> Hi Jackson, Awesome catch - thanks! The reason we don't check for -1 is probably due to the fact Graal came from Maxine VM which handles a SIGFPE caused by Integer.MIN_VALUE/-1 explicitly: https://github.com/dougxc/maxine/blob/master/com.oracle.max.vm.native/substrate/trap.c#L232 I'm not sure why HotSpot doesn't do this. In any case, we obviously need to handle this properly in Graal and will take your PR as the starting point. -Doug > On 1 Dec 2017, at 09:17, Jackson Davis wrote: > > I should add that this "fix" is based on the idea that letting the idiv > throw the SIGFPE is, in fact, the desired / expected behavior here. C2 > handles this case by adding guards. > > -Jackson > > On Fri, Dec 1, 2017 at 12:04 AM, Jackson Davis wrote: > >> One afternoon over Thanksgiving break I hacked together a very basic >> fuzzer for JVM JITs (https://github.com/jcdavis/kabur/) which much to my >> surprise actually managed to find an issue in Graal :) >> This minimal test case reliably crashes the JVM from an unhandled SIGFPE: >> >> public class Crasher { >> public static int crash(int n, int d) { >> return n/(d|1); >> } >> public static void main(String[] args) { >> for(int i = 0; i < 100000; i++) { >> crash(i, i+1); >> } >> crash(Integer.MIN_VALUE, -1); >> } >> } >> Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation >> -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) >> >> The source of this issue appears to be that IntegerDivRemNode.canDeoptimize >> only checks whether or not the denominator can be 0, not whether it can >> also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt >> info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know >> what to do and dies. Adding the -1 check seems to make this to work as >> intended (AFAICT). I have a PR for a basic fix here: >> https://github.com/graalvm/graal/pull/266 >> >> Unfortunately this check breaks CountedLoopTest in a non-obvious way, >> which is where I am out of my depth. It seems the test's CheckGraphPhase >> introduces a SignedDivNode, however since this runs after >> FrameStateAssignmentPhase, there is no frame data, so an assert fails in >> the lowering. This seems to be fundamentally broken regardless of my >> change, but only started failing here since the denominator has as stamp of >> (-65536,-1) >> >> -Jackson >> >> >> From doug.simon at oracle.com Fri Dec 1 11:43:26 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Dec 2017 12:43:26 +0100 Subject: Fwd: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE References: <7EF3FDBC-ABFD-4A20-B2AA-A0F308BABBE9@oracle.com> Message-ID: HotSpot devs, Is there some reason HotSpot doesn't (or shouldn't) handle a SIGFPE caused by Integer.MIN_VALUE/-1 explicitly? -Doug > Begin forwarded message: > > From: Doug Simon > Subject: Re: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE > Date: 1 December 2017 at 12:09:55 CET > To: Jackson Davis > Cc: graal developers > > Hi Jackson, > > Awesome catch - thanks! > > The reason we don't check for -1 is probably due to the fact Graal came from Maxine VM which handles a SIGFPE caused by Integer.MIN_VALUE/-1 explicitly: > > https://github.com/dougxc/maxine/blob/master/com.oracle.max.vm.native/substrate/trap.c#L232 > > I'm not sure why HotSpot doesn't do this. > > In any case, we obviously need to handle this properly in Graal and will take your PR as the starting point. > > -Doug > >> On 1 Dec 2017, at 09:17, Jackson Davis wrote: >> >> I should add that this "fix" is based on the idea that letting the idiv >> throw the SIGFPE is, in fact, the desired / expected behavior here. C2 >> handles this case by adding guards. >> >> -Jackson >> >> On Fri, Dec 1, 2017 at 12:04 AM, Jackson Davis wrote: >> >>> One afternoon over Thanksgiving break I hacked together a very basic >>> fuzzer for JVM JITs (https://github.com/jcdavis/kabur/) which much to my >>> surprise actually managed to find an issue in Graal :) >>> This minimal test case reliably crashes the JVM from an unhandled SIGFPE: >>> >>> public class Crasher { >>> public static int crash(int n, int d) { >>> return n/(d|1); >>> } >>> public static void main(String[] args) { >>> for(int i = 0; i < 100000; i++) { >>> crash(i, i+1); >>> } >>> crash(Integer.MIN_VALUE, -1); >>> } >>> } >>> Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation >>> -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) >>> >>> The source of this issue appears to be that IntegerDivRemNode.canDeoptimize >>> only checks whether or not the denominator can be 0, not whether it can >>> also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt >>> info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know >>> what to do and dies. Adding the -1 check seems to make this to work as >>> intended (AFAICT). I have a PR for a basic fix here: >>> https://github.com/graalvm/graal/pull/266 >>> >>> Unfortunately this check breaks CountedLoopTest in a non-obvious way, >>> which is where I am out of my depth. It seems the test's CheckGraphPhase >>> introduces a SignedDivNode, however since this runs after >>> FrameStateAssignmentPhase, there is no frame data, so an assert fails in >>> the lowering. This seems to be fundamentally broken regardless of my >>> change, but only started failing here since the denominator has as stamp of >>> (-65536,-1) >>> >>> -Jackson >>> >>> >>> > From gilles.m.duboscq at oracle.com Fri Dec 1 12:04:48 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 1 Dec 2017 13:04:48 +0100 Subject: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE In-Reply-To: References: Message-ID: I agree that it's a problem to add those Div nodes after FrameState assignement in `CountedLoopTest`. We would need to change the tests in `checkMidTierGraph` to be inserted in the `MidTier` before `FrameStateAssignmentPhase`. It can be done by overriding `createSuites` and inserting a phase manually. Gilles On 01/12/17 09:04, Jackson Davis wrote: > One afternoon over Thanksgiving break I hacked together a very basic fuzzer > for JVM JITs (https://github.com/jcdavis/kabur/) which much to my surprise > actually managed to find an issue in Graal :) > This minimal test case reliably crashes the JVM from an unhandled SIGFPE: > > public class Crasher { > public static int crash(int n, int d) { > return n/(d|1); > } > public static void main(String[] args) { > for(int i = 0; i < 100000; i++) { > crash(i, i+1); > } > crash(Integer.MIN_VALUE, -1); > } > } > Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation > -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) > > The source of this issue appears to be that IntegerDivRemNode.canDeoptimize > only checks whether or not the denominator can be 0, not whether it can > also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt > info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know > what to do and dies. Adding the -1 check seems to make this to work as > intended (AFAICT). I have a PR for a basic fix here: > https://github.com/graalvm/graal/pull/266 > > Unfortunately this check breaks CountedLoopTest in a non-obvious way, which > is where I am out of my depth. It seems the test's CheckGraphPhase > introduces a SignedDivNode, however since this runs after > FrameStateAssignmentPhase, there is no frame data, so an assert fails in > the lowering. This seems to be fundamentally broken regardless of my > change, but only started failing here since the denominator has as stamp of > (-65536,-1) > > -Jackson > From roland.schatz at oracle.com Fri Dec 1 12:53:46 2017 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 1 Dec 2017 13:53:46 +0100 Subject: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE In-Reply-To: References: Message-ID: On 12/01/2017 01:04 PM, Gilles Duboscq wrote: > I agree that it's a problem to add those Div nodes after FrameState assignement in `CountedLoopTest`. > > We would need to change the tests in `checkMidTierGraph` to be inserted in the `MidTier` before `FrameStateAssignmentPhase`. > It can be done by overriding `createSuites` and inserting a phase manually. Or we just use `checkHighTierGraph`. All the loop optimizations that could potentially break this test are in the high tier, so I think it's sufficient to do the check at the end of high tier. - Roland > > Gilles > > On 01/12/17 09:04, Jackson Davis wrote: >> One afternoon over Thanksgiving break I hacked together a very basic fuzzer >> for JVM JITs (https://github.com/jcdavis/kabur/) which much to my surprise >> actually managed to find an issue in Graal :) >> This minimal test case reliably crashes the JVM from an unhandled SIGFPE: >> >> public class Crasher { >> public static int crash(int n, int d) { >> return n/(d|1); >> } >> public static void main(String[] args) { >> for(int i = 0; i < 100000; i++) { >> crash(i, i+1); >> } >> crash(Integer.MIN_VALUE, -1); >> } >> } >> Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation >> -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) >> >> The source of this issue appears to be that IntegerDivRemNode.canDeoptimize >> only checks whether or not the denominator can be 0, not whether it can >> also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt >> info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know >> what to do and dies. Adding the -1 check seems to make this to work as >> intended (AFAICT). I have a PR for a basic fix here: >> https://github.com/graalvm/graal/pull/266 >> >> Unfortunately this check breaks CountedLoopTest in a non-obvious way, which >> is where I am out of my depth. It seems the test's CheckGraphPhase >> introduces a SignedDivNode, however since this runs after >> FrameStateAssignmentPhase, there is no frame data, so an assert fails in >> the lowering. This seems to be fundamentally broken regardless of my >> change, but only started failing here since the denominator has as stamp of >> (-65536,-1) >> >> -Jackson >> From codrut.stancu at oracle.com Mon Dec 4 23:45:55 2017 From: codrut.stancu at oracle.com (Codrut Stancu) Date: Mon, 04 Dec 2017 15:45:55 -0800 Subject: Native image compilation error In-Reply-To: References: <6pt2bsus0rocefn9ja456be2.1511042679532@email.android.com> <1511222059.16129.3.camel@oracle.com> Message-ID: <1512431155.25697.39.camel@oracle.com> Hi Leonardo, The GraalVM 0.30 release is available for download from OTN (http://www .oracle.com/technetwork/oracle-labs/program- languages/overview/index.html) as usual. It supports reflection and you can find an example in the?graalvm-0.30/examples/native-image/README.md file. The reflection support is currently experimental and we are ironing out potential wrinkles as we expand our use of this feature. For Jackson we are investigating the possibility to pre-process the ?Jackson annotations and register the reflexively accessed elements automatically. At this point you'll have to write the reflexion configuration files manually. Codrut Stancu On Tue, 2017-11-21 at 00:07 +0000, Leonardo Loch Zanivan wrote: > Awesome! Thank you for letting me know. I'm looking forward to use it > soon. > > Cheers > > On Mon, Nov 20, 2017 at 9:54 PM Codrut Stancu > om> wrote: > > Hi Leonardo, > > > > Reflection is not supported in the current native-image released > > binary. It should be supported in the next release. The release > > will > > also include a small example to get you started. > > > > Codrut Stancu > > > > On Sat, 2017-11-18 at 14:04 -0800, Codrut Stancu wrote: > > > We actually do support reflection in SVM, but you have to specify > > the > > > reflexively accessed elements using some descriptor files. That's > > a > > > limitation of the closed world assumption. The only feature > > that's > > > not supported is dynamic class loading. We haven't experimented > > with > > > Jackson yet. I'll get back later with more details (on my phone > > right > > > now). > > > > > > Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr > > rr.d > > > e> wrote: > > > > > > > > > > > > Hi Leonardo:? > > > > > > > > > > > > > > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan > > l.co > > > > > m> wrote:? > > > > > > > > > > I only read some mentions about Classloading limitations.? > > > > > > > > > > All the JSON serializers I know uses Reflection APIs, so I > > > > > suppose this is something to be supported in future > > releases.? > > > > I don?t know. But, you really need the closed world assumption > > to > > > > make AOT compilation in the way it is supposed to work for > > Truffle > > > > languages.? > > > > So, I wouldn?t expect that this is going to be addressed any > > time > > > > soon?? > > > > > > > > Best regards? > > > > Stefan? > > > > > > From pangalz at gmail.com Tue Dec 5 15:20:58 2017 From: pangalz at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 Dec 2017 15:20:58 +0000 Subject: Native image compilation error In-Reply-To: <1512431155.25697.39.camel@oracle.com> References: <6pt2bsus0rocefn9ja456be2.1511042679532@email.android.com> <1511222059.16129.3.camel@oracle.com> <1512431155.25697.39.camel@oracle.com> Message-ID: Hi Codrut, I've downloaded latest version and tried the reflection stuff. It worked very well with a sample bean and Jackson. Thank you so much! Although, I found a few issues while testing other samples, I'll send follow up emails. Here's my sample Bean: package panga.test.graal; public class Car { private String name; public Car(String name) { this.name = name; } public void setName(String name) { this.name = name; } public String getName() { return name; } } Main method: package panga.test.graal; import com.fasterxml.jackson.databind.ObjectMapper; public class Main { public static void main(String... args) throws Throwable { final Car ferrari = new Car("Ferrari"); ObjectMapper mapper = new ObjectMapper(); System.out.println(mapper.writeValueAsString(ferrari)); } } Reflection configuration: [{ "name" : "panga.test.graal.Car", "allDeclaredMethods" : "true", "allDeclaredFields" : "true", "allPublicFields" : "true", "allPublicMethods" : "false" }] Command used to create image: *native-image -jar test.jar -H:+ReportUnsupportedElementsAtRuntime -H:ReflectionConfigurationFiles=test.json* NOTE: If I set "allPublicMethods": "true" the following error happens: classlist: 1,180.50 ms (cap): 6,728.02 ms setup: 7,493.71 ms (typeflow): 4,005.06 ms (objects): 1,792.39 ms (features): 3.51 ms analysis: 5,963.47 ms universe: 135.11 ms fatal error: com.oracle.svm.core.util.VMError$HostedError: UNSUPPORTED FEATURE: wait/notify called on non-instance type: char[] at com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:74) at com.oracle.svm.hosted.meta.UniverseBuilder.collectWaitNotifyFieldInfo(UniverseBuilder.java:733) at com.oracle.svm.hosted.meta.UniverseBuilder.build(UniverseBuilder.java:127) at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:688) at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:349) at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:221) at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:312) at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:58) Error: Image building with exit status 1 On Mon, Dec 4, 2017 at 9:46 PM Codrut Stancu wrote: > Hi Leonardo, > > The GraalVM 0.30 release is available for download from OTN ( > http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html) > as usual. It supports reflection and you can find an example in the graalvm-0.30/examples/native-image/README.md > file. The reflection support is currently experimental and we are ironing > out potential wrinkles as we expand our use of this feature. For Jackson we > are investigating the possibility to pre-process the Jackson annotations > and register the reflexively accessed elements automatically. At this point > you'll have to write the reflexion configuration files manually. > > Codrut Stancu > > > On Tue, 2017-11-21 at 00:07 +0000, Leonardo Loch Zanivan wrote: > > Awesome! Thank you for letting me know. I'm looking forward to use it soon. > > Cheers > > On Mon, Nov 20, 2017 at 9:54 PM Codrut Stancu > wrote: > > Hi Leonardo, > > Reflection is not supported in the current native-image released > binary. It should be supported in the next release. The release will > also include a small example to get you started. > > Codrut Stancu > > On Sat, 2017-11-18 at 14:04 -0800, Codrut Stancu wrote: > > We actually do support reflection in SVM, but you have to specify the > > reflexively accessed elements using some descriptor files. That's a > > limitation of the closed world assumption. The only feature that's > > not supported is dynamic class loading. We haven't experimented with > > Jackson yet. I'll get back later with more details (on my phone right > > now). > > > > Codrut StancuOn Nov 18, 2017 1:18 PM, Stefan Marr > e> wrote: > > > > > > > > > Hi Leonardo: > > > > > > > > > > > On 18 Nov 2017, at 21:10, Leonardo Loch Zanivan > > > m> wrote: > > > > > > > > I only read some mentions about Classloading limitations. > > > > > > > > All the JSON serializers I know uses Reflection APIs, so I > > > > suppose this is something to be supported in future releases. > > > I don?t know. But, you really need the closed world assumption to > > > make AOT compilation in the way it is supposed to work for Truffle > > > languages. > > > So, I wouldn?t expect that this is going to be addressed any time > > > soon? > > > > > > Best regards > > > Stefan > > > > > From leonardo.zanivan at gmail.com Tue Dec 5 15:23:58 2017 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 Dec 2017 15:23:58 +0000 Subject: graalvm-0.30 native-image NPE on Linux Message-ID: Hi, native-image not working on my Linux, even with HelloWorld sample. *$ native-image -verbose HelloWorld* Executing [ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ -server \ -XX:+UnlockExperimentalVMOptions \ -XX:+EnableJVMCI \ -XX:-UseJVMCIClassLoader \ -XX:+UseJVMCICompiler \ -Dgraal.CompileGraalWithC1Only=false \ -d64 \ -noverify \ -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/boot/graaljs-scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/boot/graal-sdk.jar \ -cp \ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm-enterprise.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-hotspot.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/enterprise-graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/graal.jar \ -Duser.country=US \ -Duser.language=en \ -Dgraal.EagerSnippets=true \ -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ -Dgraalvm.version=0.30 \ -Dorg.graalvm.version=0.30 \ -Xms1G \ -Xss10m \ -Dcom.oracle.graalvm.isaot=true \ com.oracle.svm.hosted.NativeImageGeneratorRunner \ -imagecp \ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm-enterprise.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-hotspot.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/enterprise-graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/library-support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native-image \ -H:Path=. \ -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/inspect \ -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/clibraries/linux-amd64 \ -H:Class=HelloWorld \ -H:Name=helloworld ] classlist: 1,800.75 ms (cap): 486.01 ms setup: 826.72 ms fatal error: java.lang.NullPointerException at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) at com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImageGenerator.java:642) at com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:39) at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:642) at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:349) at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:221) at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:312) at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:58) Error: Image building with exit status 1 Environment: Ubuntu 16.10 on VirtualBox Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux From pangalz at gmail.com Tue Dec 5 15:32:53 2017 From: pangalz at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 Dec 2017 15:32:53 +0000 Subject: native-image usage with NativePRNG secure random algorithm Message-ID: Native image compilation doesn't work when using NativePRNG secure random algorithm (enabled by default on Linux/MacOS), causing a simple UUID.randomUUID fail. Note: Disabling NativePRNG in java.security file from GraalVM folder works. HelloWorld class: import java.util.UUID; public class HelloWorld { public static void main(String[] args) { System.out.println(*UUID.randomUUID().toString()*); } } *$ native-image -verbose HelloWorld* Executing [ /Downloads/graalvm-0.30/Contents/Home/jre/bin/java \ -server \ -XX:+UnlockExperimentalVMOptions \ -XX:+EnableJVMCI \ -XX:-UseJVMCIClassLoader \ -XX:+UseJVMCICompiler \ -Dgraal.CompileGraalWithC1Only=false \ -d64 \ -noverify \ -Xbootclasspath/a:/Downloads/graalvm-0.30/Contents/Home/jre/lib/boot/graaljs-scriptengine.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/boot/graal-sdk.jar \ -cp \ /Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/svm.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/objectfile.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/pointsto.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/svm-enterprise.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/graal.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/enterprise-graal.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/jvmci-api.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/jvmci-hotspot.jar \ -Duser.country=US \ -Duser.language=en \ -Dgraal.EagerSnippets=true \ -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ -Dgraalvm.version=0.30 \ -Dorg.graalvm.version=0.30 \ -Xms1G \ -Xss10m \ -Dcom.oracle.graalvm.isaot=true \ com.oracle.svm.hosted.NativeImageGeneratorRunner \ -imagecp \ /Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/svm.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/objectfile.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/pointsto.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/svm-enterprise.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/graal.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/enterprise-graal.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/jvmci-api.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/jvmci/jvmci-hotspot.jar:/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/library-support.jar:/Downloads/graalvm-0.30/Contents/Home/examples/native-image \ -H:Path=. \ -H:InspectServerContentPath=/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/inspect \ -H:CLibraryPath=/Downloads/graalvm-0.30/Contents/Home/jre/lib/svm/clibraries/darwin-amd64 \ -H:Class=HelloWorld \ -H:Name=helloworld ] classlist: 919.94 ms (cap): 1,034.18 ms setup: 1,766.95 ms analysis: 3,921.37 ms error: Must not have a FileDescriptor in the image heap. Detailed message: Error: Must not have a FileDescriptor in the image heap. Trace: object java.io.FileInputStream object sun.security.provider.NativePRNG$RandomIO method sun.security.provider.NativePRNG.engineNextBytes(byte[]) Call path from entry point to sun.security.provider.NativePRNG.engineNextBytes(byte[]): at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:220) at java.security.SecureRandom.nextBytes(SecureRandom.java:468) at java.util.UUID.randomUUID(UUID.java:145) at HelloWorld.main(HelloWorld.java:6) at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:137) at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0) Error: Image building with exit status 1 From pangalz at gmail.com Tue Dec 5 15:33:16 2017 From: pangalz at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 Dec 2017 15:33:16 +0000 Subject: graalvm-0.30 native-image NPE on Linux In-Reply-To: References: Message-ID: Hi, native-image not working on my Linux, even with HelloWorld sample. *$ native-image -verbose HelloWorld* Executing [ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ -server \ -XX:+UnlockExperimentalVMOptions \ -XX:+EnableJVMCI \ -XX:-UseJVMCIClassLoader \ -XX:+UseJVMCICompiler \ -Dgraal.CompileGraalWithC1Only=false \ -d64 \ -noverify \ -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/boot/graaljs-scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/boot/graal-sdk.jar \ -cp \ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm-enterprise.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-hotspot.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/enterprise-graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/graal.jar \ -Duser.country=US \ -Duser.language=en \ -Dgraal.EagerSnippets=true \ -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ -Dgraalvm.version=0.30 \ -Dorg.graalvm.version=0.30 \ -Xms1G \ -Xss10m \ -Dcom.oracle.graalvm.isaot=true \ com.oracle.svm.hosted.NativeImageGeneratorRunner \ -imagecp \ /home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/svm-enterprise.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/jvmci-hotspot.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/enterprise-graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/library-support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native-image \ -H:Path=. \ -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/inspect \ -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm-0.30/jre/lib/svm/clibraries/linux-amd64 \ -H:Class=HelloWorld \ -H:Name=helloworld ] classlist: 1,800.75 ms (cap): 486.01 ms setup: 826.72 ms fatal error: java.lang.NullPointerException at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) at com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImageGenerator.java:642) at com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:39) at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:642) at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:349) at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:221) at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:312) at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:58) Error: Image building with exit status 1 Environment: Ubuntu 16.10 on VirtualBox Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux From pangalz at gmail.com Tue Dec 5 15:51:55 2017 From: pangalz at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 Dec 2017 15:51:55 +0000 Subject: native-image Bytecode parsing error Message-ID: I'm trying to create an image from a simple Jetty (9.4.8.v20171121) web application and I got the following error: error: unsupported features in 3 methods Detailed message: Error: Bytecode parsing error: Must not have a Thread in the image heap. Trace: at parsing org.eclipse.jetty.util.thread.ShutdownThread.deregister(ShutdownThread.java:117) Call path from entry point to org.eclipse.jetty.util.thread.ShutdownThread.deregister(LifeCycle): at org.eclipse.jetty.util.thread.ShutdownThread.deregister(ShutdownThread.java:117) at org.eclipse.jetty.server.Server.doStop(Server.java:497) at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89) at org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.stopLifeCycles(ShutdownMonitor.java:443) at org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.run(ShutdownMonitor.java:386) at java.lang.Thread.run(Thread.java:748) at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:188) at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0) Error: Bytecode parsing error: Must not have a Thread in the image heap. Trace: at parsing org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(ShutdownThread.java:125) Call path from entry point to org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(LifeCycle): at org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(ShutdownThread.java:125) at org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable$$Lambda$449/1436526075.test(Unknown Source) at org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.stopLifeCycles(ShutdownMonitor.java:442) at org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.run(ShutdownMonitor.java:386) at java.lang.Thread.run(Thread.java:748) at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:188) at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0) Error: Bytecode parsing error: Must not have a Thread in the image heap. Trace: at parsing org.eclipse.jetty.util.thread.ShutdownThread.register(ShutdownThread.java:101) Call path from entry point to org.eclipse.jetty.util.thread.ShutdownThread.register(LifeCycle[]): at org.eclipse.jetty.util.thread.ShutdownThread.register(ShutdownThread.java:101) at org.eclipse.jetty.server.Server.doStart(Server.java:361) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at panga.jetty.graal.Main.main(Main.java:31) at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:137) at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0) Main class: package panga.jetty.graal; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.eclipse.jetty.server.Request; import org.eclipse.jetty.server.Server; import org.eclipse.jetty.server.handler.AbstractHandler; public class Main extends AbstractHandler { @Override public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setContentType("text/html; charset=utf-8"); response.setStatus(HttpServletResponse.SC_OK); response.getWriter().println("Hello World"); baseRequest.setHandled(true); } public static void main(String[] args) throws Exception { Server server = new Server(8080); server.setHandler(new Main()); server.start(); server.join(); } } Command: $ native-image -jar jetty-graal-1.0-SNAPSHOT-fat.jar -H:+ReportUnsupportedElementsAtRuntime Note: GraalVM 0.30 From vojin.jovanovic at oracle.com Tue Dec 5 17:25:55 2017 From: vojin.jovanovic at oracle.com (Vojin Jovanovic) Date: Tue, 5 Dec 2017 18:25:55 +0100 Subject: native-image Bytecode parsing error In-Reply-To: References: Message-ID: Hi Leonardo, This is a known limitation of `native-image`: we do not support storing threads in the image heap. We have a fix for this in the pipeline; this will be supported with the next version of GraalVM. Best regards, - Vojin On 05.12.17 16:51, Leonardo Loch Zanivan wrote: > I'm trying to create an image from a simple Jetty (9.4.8.v20171121) web > application and I got the following error: > > error: unsupported features in 3 methods > > Detailed message: > > Error: Bytecode parsing error: Must not have a Thread in the image heap. > > Trace: > > at parsing > org.eclipse.jetty.util.thread.ShutdownThread.deregister(ShutdownThread.java:117) > > Call path from entry point to > org.eclipse.jetty.util.thread.ShutdownThread.deregister(LifeCycle): > > at > org.eclipse.jetty.util.thread.ShutdownThread.deregister(ShutdownThread.java:117) > > at org.eclipse.jetty.server.Server.doStop(Server.java:497) > > at > org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89) > > at > org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.stopLifeCycles(ShutdownMonitor.java:443) > > at > org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.run(ShutdownMonitor.java:386) > > at java.lang.Thread.run(Thread.java:748) > > at > com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:188) > > at > Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0) > > Error: Bytecode parsing error: Must not have a Thread in the image heap. > > Trace: > > at parsing > org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(ShutdownThread.java:125) > > Call path from entry point to > org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(LifeCycle): > > at > org.eclipse.jetty.util.thread.ShutdownThread.isRegistered(ShutdownThread.java:125) > > at > org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable$$Lambda$449/1436526075.test(Unknown > Source) > > at > org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.stopLifeCycles(ShutdownMonitor.java:442) > > at > org.eclipse.jetty.server.ShutdownMonitor$ShutdownMonitorRunnable.run(ShutdownMonitor.java:386) > > at java.lang.Thread.run(Thread.java:748) > > at > com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:188) > > at > Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0) > > Error: Bytecode parsing error: Must not have a Thread in the image heap. > > Trace: > > at parsing > org.eclipse.jetty.util.thread.ShutdownThread.register(ShutdownThread.java:101) > > Call path from entry point to > org.eclipse.jetty.util.thread.ShutdownThread.register(LifeCycle[]): > > at > org.eclipse.jetty.util.thread.ShutdownThread.register(ShutdownThread.java:101) > > at org.eclipse.jetty.server.Server.doStart(Server.java:361) > > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > > at panga.jetty.graal.Main.main(Main.java:31) > > at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:137) > > at > Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0) > > Main class: > > package panga.jetty.graal; > > import java.io.IOException; > > import javax.servlet.ServletException; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > > import org.eclipse.jetty.server.Request; > import org.eclipse.jetty.server.Server; > import org.eclipse.jetty.server.handler.AbstractHandler; > > public class Main extends AbstractHandler { > > @Override > public void handle(String target, > Request baseRequest, > HttpServletRequest request, > HttpServletResponse response) throws IOException, > ServletException { > response.setContentType("text/html; charset=utf-8"); > response.setStatus(HttpServletResponse.SC_OK); > response.getWriter().println("Hello World"); > baseRequest.setHandled(true); > } > > public static void main(String[] args) throws Exception { > Server server = new Server(8080); > server.setHandler(new Main()); > > server.start(); > server.join(); > } > } > > Command: > > $ native-image -jar jetty-graal-1.0-SNAPSHOT-fat.jar > -H:+ReportUnsupportedElementsAtRuntime > > Note: GraalVM 0.30 From adam at cs.miami.edu Sun Dec 10 01:27:35 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Sat, 9 Dec 2017 20:27:35 -0500 Subject: java graal.js interop Message-ID: Hi, I am unsure if this is the best place to post user questions about Graal.js, I am not able to get the JS examples working that use Java. I get the following error: ReferenceError: Java is not defined It seems that Java.type(String), is not defined. I am running Graal.js by using "js myscript.js" on Ubuntu 16, graalvm-0.30. Best, -Adam M. From boris.spasojevic at oracle.com Sun Dec 10 07:24:36 2017 From: boris.spasojevic at oracle.com (boris.spasojevic) Date: Sun, 10 Dec 2017 08:24:36 +0100 Subject: java graal.js interop In-Reply-To: Message-ID: <201712100724.vBA7OgYW017355@aserv0121.oracle.com> Hey Adam, I am also unsure if this is the best place to answer user questions about Graal.js but here goes :) Without going into to much detail, js executes on SVM by default. You need to run js with --jvm in order to execute on the JVM and have access to Java.So: "js --jvm myscript.js" If you need access to the other truffle languages? add --polyglot."js --polyglot myscript.js" which will run on SVM with polyglot enabled. If you want Java + other languages just add both:?"js --jvm --polyglot myscript.js"? Hope that helps. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Adam McMahon Date: 12/10/17 02:27 (GMT+01:00) To: graal-dev at openjdk.java.net Subject: java graal.js interop Hi, I am unsure if this is the best place to post user questions about Graal.js, I am not able to get the JS examples working that use Java.? I get the following error: ReferenceError: Java is not defined It seems that? Java.type(String), is not defined. I am running Graal.js by using "js myscript.js"? on Ubuntu 16, graalvm-0.30. Best, -Adam M. From adam at cs.miami.edu Sun Dec 10 08:46:22 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Sun, 10 Dec 2017 03:46:22 -0500 Subject: java graal.js interop In-Reply-To: <201712100724.vBA7OgYW017355@aserv0121.oracle.com> References: <201712100724.vBA7OgYW017355@aserv0121.oracle.com> Message-ID: Hi Boris, Thanks for the heads-up, that works well with the --jvm option. However, when I add the --jvm option, I noticed that pure JS code ran much slower (not just a slower startup, which was expected, but slower execution of pure JS). I can provide an example, if needed, but this was unexpected to me as an end user. --polyglot did not slow down the JS execution. it seems odd to me that just including the JVM as an option would slow down the Graal.js execution of pure JS. -Adam On Sun, Dec 10, 2017 at 2:24 AM, boris.spasojevic < boris.spasojevic at oracle.com> wrote: > Hey Adam, > > I am also unsure if this is the best place to answer user questions about > Graal.js but here goes :) > > Without going into to much detail, js executes on SVM by default. You need > to run js with --jvm in order to execute on the JVM and have access to Java. > So: "js --jvm myscript.js" > > If you need access to the other truffle languages add --polyglot. > "js --polyglot myscript.js" which will run on SVM with polyglot enabled. > If you want Java + other languages just add both: > "js --jvm --polyglot myscript.js" > > Hope that helps. > > Sent from my Samsung Galaxy smartphone. > > -------- Original message -------- > From: Adam McMahon > Date: 12/10/17 02:27 (GMT+01:00) > To: graal-dev at openjdk.java.net > Subject: java graal.js interop > > Hi, > > I am unsure if this is the best place to post user questions about > Graal.js, > > I am not able to get the JS examples working that use Java. I get the > following error: > > ReferenceError: Java is not defined > > It seems that Java.type(String), is not defined. I am running Graal.js by > using "js myscript.js" on Ubuntu 16, graalvm-0.30. > > Best, > > -Adam M. > From boris.spasojevic at oracle.com Sun Dec 10 09:39:00 2017 From: boris.spasojevic at oracle.com (boris.spasojevic) Date: Sun, 10 Dec 2017 10:39:00 +0100 Subject: java graal.js interop In-Reply-To: Message-ID: <201712100939.vBA9d4BU005096@userv0121.oracle.com> Hey Adam, Running with --jvm means that the js code is also executed on the JVM. Running js on the JVM requires substantially longer warm-up time than running on SVM but yields better peek performance. I'm assuming that your example just isn't running long enough to get the full benefits of the JVM.? Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Adam McMahon Date: 12/10/17 09:46 (GMT+01:00) To: "boris.spasojevic" Cc: graal-dev at openjdk.java.net Subject: Re: java graal.js interop Hi Boris, Thanks for the heads-up, that works well with the --jvm option. However, when I add the --jvm option, I noticed that pure JS code ran much slower (not just a slower startup, which was expected, but slower execution of pure JS). I can provide an example, if needed, but this was unexpected to me as an end user.? --polyglot did not slow down the JS execution.? it seems odd to me that just including the JVM as an option would slow down the Graal.js execution of pure JS. -Adam On Sun, Dec 10, 2017 at 2:24 AM, boris.spasojevic wrote: Hey Adam, I am also unsure if this is the best place to answer user questions about Graal.js but here goes :) Without going into to much detail, js executes on SVM by default. You need to run js with --jvm in order to execute on the JVM and have access to Java.So: "js --jvm myscript.js" If you need access to the other truffle languages? add --polyglot."js --polyglot myscript.js" which will run on SVM with polyglot enabled. If you want Java + other languages just add both:?"js --jvm --polyglot myscript.js"? Hope that helps. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Adam McMahon Date: 12/10/17 02:27 (GMT+01:00) To: graal-dev at openjdk.java.net Subject: java graal.js interop Hi, I am unsure if this is the best place to post user questions about Graal.js, I am not able to get the JS examples working that use Java.? I get the following error: ReferenceError: Java is not defined It seems that? Java.type(String), is not defined. I am running Graal.js by using "js myscript.js"? on Ubuntu 16, graalvm-0.30. Best, -Adam M. From christian.wirth at oracle.com Sun Dec 10 09:33:30 2017 From: christian.wirth at oracle.com (Christian Wirth) Date: Sun, 10 Dec 2017 10:33:30 +0100 Subject: java graal.js interop In-Reply-To: References: <201712100724.vBA7OgYW017355@aserv0121.oracle.com> Message-ID: <6bfea8ca-4d1d-69d4-f2b0-dd8acd1e23db@oracle.com> Hi Adam, this is quite odd. Can you please send me your code example so I can investigate. Thanks, Christian Am 10.12.2017 um 09:46 schrieb Adam McMahon: > Hi Boris, > > Thanks for the heads-up, that works well with the --jvm option. > > However, when I add the --jvm option, I noticed that pure JS code ran much > slower (not just a slower startup, which was expected, but slower execution > of pure JS). I can provide an example, if needed, but this was unexpected > to me as an end user. --polyglot did not slow down the JS execution. > > it seems odd to me that just including the JVM as an option would slow down > the Graal.js execution of pure JS. > > -Adam > > > > On Sun, Dec 10, 2017 at 2:24 AM, boris.spasojevic < > boris.spasojevic at oracle.com> wrote: > >> Hey Adam, >> >> I am also unsure if this is the best place to answer user questions about >> Graal.js but here goes :) >> >> Without going into to much detail, js executes on SVM by default. You need >> to run js with --jvm in order to execute on the JVM and have access to Java. >> So: "js --jvm myscript.js" >> >> If you need access to the other truffle languages add --polyglot. >> "js --polyglot myscript.js" which will run on SVM with polyglot enabled. >> If you want Java + other languages just add both: >> "js --jvm --polyglot myscript.js" >> >> Hope that helps. >> >> Sent from my Samsung Galaxy smartphone. >> >> -------- Original message -------- >> From: Adam McMahon >> Date: 12/10/17 02:27 (GMT+01:00) >> To: graal-dev at openjdk.java.net >> Subject: java graal.js interop >> >> Hi, >> >> I am unsure if this is the best place to post user questions about >> Graal.js, >> >> I am not able to get the JS examples working that use Java. I get the >> following error: >> >> ReferenceError: Java is not defined >> >> It seems that Java.type(String), is not defined. I am running Graal.js by >> using "js myscript.js" on Ubuntu 16, graalvm-0.30. >> >> Best, >> >> -Adam M. >> From adam at cs.miami.edu Sun Dec 10 21:21:41 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Sun, 10 Dec 2017 16:21:41 -0500 Subject: java graal.js interop In-Reply-To: <201712100939.vBA9d4BU005096@userv0121.oracle.com> References: <201712100939.vBA9d4BU005096@userv0121.oracle.com> Message-ID: Hi Boris, [1] Yes, you are completely correct and that is what I observed with regard to performance. Though in my silly little micro test, Nashorn (warmed up) beat both graal-SVM and graal-JVM. Now I think I have a better idea how Graal.js works inside or outside of JVM. [2] User group? Do you think there is enough interest in GraalVM to create a user group (perhaps a goolge group?) I would enjoy discussing GraalVM: pros/cons and use cases, but do not want to clutter the dev group. thoughts? -Adam On Sun, Dec 10, 2017 at 4:39 AM, boris.spasojevic < boris.spasojevic at oracle.com> wrote: > Hey Adam, > > Running with --jvm means that the js code is also executed on the JVM. > Running js on the JVM requires substantially longer warm-up time than > running on SVM but yields better peek performance. I'm assuming that your > example just isn't running long enough to get the full benefits of the JVM. > > > > Sent from my Samsung Galaxy smartphone. > > -------- Original message -------- > From: Adam McMahon > Date: 12/10/17 09:46 (GMT+01:00) > To: "boris.spasojevic" > Cc: graal-dev at openjdk.java.net > Subject: Re: java graal.js interop > > Hi Boris, > > Thanks for the heads-up, that works well with the --jvm option. > > However, when I add the --jvm option, I noticed that pure JS code ran much > slower (not just a slower startup, which was expected, but slower execution > of pure JS). I can provide an example, if needed, but this was unexpected > to me as an end user. --polyglot did not slow down the JS execution. > > it seems odd to me that just including the JVM as an option would slow > down the Graal.js execution of pure JS. > > -Adam > > > > On Sun, Dec 10, 2017 at 2:24 AM, boris.spasojevic < > boris.spasojevic at oracle.com> wrote: > >> Hey Adam, >> >> I am also unsure if this is the best place to answer user questions about >> Graal.js but here goes :) >> >> Without going into to much detail, js executes on SVM by default. You >> need to run js with --jvm in order to execute on the JVM and have access to >> Java. >> So: "js --jvm myscript.js" >> >> If you need access to the other truffle languages add --polyglot. >> "js --polyglot myscript.js" which will run on SVM with polyglot enabled. >> If you want Java + other languages just add both: >> "js --jvm --polyglot myscript.js" >> >> Hope that helps. >> >> Sent from my Samsung Galaxy smartphone. >> >> -------- Original message -------- >> From: Adam McMahon >> Date: 12/10/17 02:27 (GMT+01:00) >> To: graal-dev at openjdk.java.net >> Subject: java graal.js interop >> >> Hi, >> >> I am unsure if this is the best place to post user questions about >> Graal.js, >> >> I am not able to get the JS examples working that use Java. I get the >> following error: >> >> ReferenceError: Java is not defined >> >> It seems that Java.type(String), is not defined. I am running Graal.js by >> using "js myscript.js" on Ubuntu 16, graalvm-0.30. >> >> Best, >> >> -Adam M. >> > > From thomas.wuerthinger at oracle.com Sun Dec 10 22:18:40 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sun, 10 Dec 2017 23:18:40 +0100 Subject: java graal.js interop In-Reply-To: References: <201712100939.vBA9d4BU005096@userv0121.oracle.com> Message-ID: <2ABE42E6-463B-4573-9866-90183E53B90C@oracle.com> Adam, We will soon introduce extra user group mailing lists. For now, feel free to discuss here ;). Please share your micro tests so we can verify results. Thanks, thomas > On 10 Dec 2017, at 22:21, Adam McMahon wrote: > > Hi Boris, > > [1] Yes, you are completely correct and that is what I observed with regard > to performance. Though in my silly little micro test, Nashorn (warmed up) > beat both graal-SVM and graal-JVM. Now I think I have a better idea how > Graal.js works inside or outside of JVM. > > [2] User group? Do you think there is enough interest in GraalVM to > create a user group (perhaps a goolge group?) I would enjoy discussing > GraalVM: pros/cons and use cases, but do not want to clutter the dev group. > thoughts? > > -Adam > > On Sun, Dec 10, 2017 at 4:39 AM, boris.spasojevic < > boris.spasojevic at oracle.com> wrote: > >> Hey Adam, >> >> Running with --jvm means that the js code is also executed on the JVM. >> Running js on the JVM requires substantially longer warm-up time than >> running on SVM but yields better peek performance. I'm assuming that your >> example just isn't running long enough to get the full benefits of the JVM. >> >> >> >> Sent from my Samsung Galaxy smartphone. >> >> -------- Original message -------- >> From: Adam McMahon >> Date: 12/10/17 09:46 (GMT+01:00) >> To: "boris.spasojevic" >> Cc: graal-dev at openjdk.java.net >> Subject: Re: java graal.js interop >> >> Hi Boris, >> >> Thanks for the heads-up, that works well with the --jvm option. >> >> However, when I add the --jvm option, I noticed that pure JS code ran much >> slower (not just a slower startup, which was expected, but slower execution >> of pure JS). I can provide an example, if needed, but this was unexpected >> to me as an end user. --polyglot did not slow down the JS execution. >> >> it seems odd to me that just including the JVM as an option would slow >> down the Graal.js execution of pure JS. >> >> -Adam >> >> >> >> On Sun, Dec 10, 2017 at 2:24 AM, boris.spasojevic < >> boris.spasojevic at oracle.com> wrote: >> >>> Hey Adam, >>> >>> I am also unsure if this is the best place to answer user questions about >>> Graal.js but here goes :) >>> >>> Without going into to much detail, js executes on SVM by default. You >>> need to run js with --jvm in order to execute on the JVM and have access to >>> Java. >>> So: "js --jvm myscript.js" >>> >>> If you need access to the other truffle languages add --polyglot. >>> "js --polyglot myscript.js" which will run on SVM with polyglot enabled. >>> If you want Java + other languages just add both: >>> "js --jvm --polyglot myscript.js" >>> >>> Hope that helps. >>> >>> Sent from my Samsung Galaxy smartphone. >>> >>> -------- Original message -------- >>> From: Adam McMahon >>> Date: 12/10/17 02:27 (GMT+01:00) >>> To: graal-dev at openjdk.java.net >>> Subject: java graal.js interop >>> >>> Hi, >>> >>> I am unsure if this is the best place to post user questions about >>> Graal.js, >>> >>> I am not able to get the JS examples working that use Java. I get the >>> following error: >>> >>> ReferenceError: Java is not defined >>> >>> It seems that Java.type(String), is not defined. I am running Graal.js by >>> using "js myscript.js" on Ubuntu 16, graalvm-0.30. >>> >>> Best, >>> >>> -Adam M. >>> >> >> From jaroslav.tulach at oracle.com Mon Dec 11 08:27:53 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 11 Dec 2017 09:27:53 +0100 Subject: java graal.js interop In-Reply-To: References: Message-ID: <2183947.hK0IChQ46k@pracovni> Hello Adam, FYI, there is https://github.com/graalvm/graal-js-archetype which helps to over come initial setup problems. It may help you too. Best regards. -jt On sobota 9. prosince 2017 20:27:35 CET Adam McMahon wrote: > Hi, > > I am unsure if this is the best place to post user questions about Graal.js, > > I am not able to get the JS examples working that use Java. I get the > following error: > > ReferenceError: Java is not defined > > It seems that Java.type(String), is not defined. I am running Graal.js by > using "js myscript.js" on Ubuntu 16, graalvm-0.30. > > Best, > > -Adam M. From java at stefan-marr.de Mon Dec 11 11:18:38 2017 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 11 Dec 2017 11:18:38 +0000 Subject: [MoreVMs'18] Call for Contributions: 2nd Workshop on Modern Language Runtimes, Ecosystems, and VMs at 2018 Message-ID: ============================================================================ Call for Papers: MoreVMs'18 2nd Workshop on Modern Language Runtimes, and Ecosystems Co-located with '18 April 9th, 2018, Nice, France https://2018.programming-conference.org/track/MoreVMs-2018 ============================================================================ The MoreVMs'18 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design and compilation strategies. The workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions, from either an academic or industrial perspective. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- Submissions should use the ACM Conference acmart Format with the ?sigconf? option with a font size of 10 point and the font family Times New Roman. All submissions should be in PDF format. If you use LaTeX or Word, please use the provided ACM acmart templates. Otherwise, please follow the ACM author instructions. https://www.acm.org/publications/proceedings-template If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission for review using the LaTeX command \settopmatter{printfolios=true} (see examples in template). Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission details will be on: https://2018.programming-conference.org/track/MoreVMs-2018 Important Dates --------------- Extended abstract submission: 2018-01-26 Author notification: 2018-02-23 Workshop: 2018-04-09 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- Cl?ment Bera, Inria Lille Nord Europe, France Maxime Chevalier-Boisvert, University of Montreal, Canada S?bastien Doeraene, EPFL, Switzerland Johan Fabry, Raincode Labs, Belgium Juliana Franco, Imperial College London, United Kingdom Tobias Grosser, ETH Zurich, Switzerland Ben L. Titzer, Google, Germany Niko Matsakis, Mozilla Research, United States Armin Rigo, PyPy, Switzerland Maoni Stephens, Microsoft, United States Ga?l Thomas, Telecom SudParis, France Mario Wolczko, Oracle Labs, United States Workshop Organizers ------------------- Edd Barrett, King's College London, United Kingdom Adam Welc, Uber Technologies, United States Stefan Marr, University of Kent, United Kingdom From codrut.stancu at oracle.com Tue Dec 12 04:05:23 2017 From: codrut.stancu at oracle.com (Codrut Stancu) Date: Mon, 11 Dec 2017 20:05:23 -0800 Subject: graalvm-0.30 native-image NPE on Linux In-Reply-To: References: Message-ID: <1513051523.16135.8.camel@oracle.com> Hi Leonardo, We released a new version (graalvm-0.30.1) that fixes the NPE. The NPE was thrown on an exception path and was hiding the real reason for the crash that you reported. We were able to determine that from the trace that you provided, however, we were not able to reproduce the crash. Please download the new binaries and run the examples again. You will most likely encounter the exception that was hidden by the NPE and that should take us one step closer. Regards, Codrut Stancu On Tue, 2017-12-05 at 15:33 +0000, Leonardo Loch Zanivan wrote: > Hi, > > native-image not working on my Linux, even with HelloWorld sample. > > *$ native-image -verbose HelloWorld* > > Executing [ > /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ > -server \ > -XX:+UnlockExperimentalVMOptions \ > -XX:+EnableJVMCI \ > -XX:-UseJVMCIClassLoader \ > -XX:+UseJVMCICompiler \ > -Dgraal.CompileGraalWithC1Only=false \ > -d64 \ > -noverify \ > -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/boot/graaljs- > scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/boot/graal-sdk.jar > \ > -cp \ > /home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/svm- > enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/jvmci- > hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/enterprise- > graal.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/graal.jar > \ > -Duser.country=US \ > -Duser.language=en \ > -Dgraal.EagerSnippets=true \ > -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ > -Dgraalvm.version=0.30 \ > -Dorg.graalvm.version=0.30 \ > -Xms1G \ > -Xss10m \ > -Dcom.oracle.graalvm.isaot=true \ > com.oracle.svm.hosted.NativeImageGeneratorRunner \ > -imagecp \ > /home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/svm- > enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/jvmci- > hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/enterprise- > graal.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/library- > support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native- > image > \ > -H:Path=. \ > -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/inspect > \ > -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm- > 0.30/jre/lib/svm/clibraries/linux-amd64 > \ > -H:Class=HelloWorld \ > -H:Name=helloworld > ] > ???classlist:???1,800.75 ms > ???????(cap):?????486.01 ms > ???????setup:?????826.72 ms > fatal error: java.lang.NullPointerException > at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) > at > com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImage > Generator.java:642) > at > com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.ja > va:39) > at > com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator > .java:642) > at > com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.j > ava:349) > at > com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeIma > geGeneratorRunner.java:221) > at > com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGen > eratorRunner.java:312) > at > com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGene > ratorRunner.java:58) > Error: Image building with exit status 1 > > Environment: > Ubuntu 16.10 on VirtualBox > Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 > UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux From pangalz at gmail.com Tue Dec 12 14:10:55 2017 From: pangalz at gmail.com (Leonardo Loch Zanivan) Date: Tue, 12 Dec 2017 14:10:55 +0000 Subject: graalvm-0.30 native-image NPE on Linux In-Reply-To: <1513051523.16135.8.camel@oracle.com> References: <1513051523.16135.8.camel@oracle.com> Message-ID: Hi Codrut, You were right, after trying HelloWorld example with the latest build I got the following error: $ native-image -verbose HelloWorld Executing [ /graalvm-0.30.1/jre/bin/java \ -server \ -XX:+UnlockExperimentalVMOptions \ -XX:+EnableJVMCI \ -XX:-UseJVMCIClassLoader \ -XX:+UseJVMCICompiler \ -Dgraal.CompileGraalWithC1Only=false \ -d64 \ -noverify \ -Xbootclasspath/a:/graalvm-0.30.1/jre/lib/boot/graaljs-scriptengine.jar:/graalvm-0.30.1/jre/lib/boot/graal-sdk.jar \ -cp \ /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar \ -Duser.country=US \ -Duser.language=en \ -Dgraal.EagerSnippets=true \ -Dsubstratevm.version=2b30530bbcf4c190cd9bbdb941b7f2a9fcf66e8e \ -Dgraalvm.version=0.30.1 \ -Dorg.graalvm.version=0.30.1 \ -Xms1G \ -Xss10m \ -Dcom.oracle.graalvm.isaot=true \ com.oracle.svm.hosted.NativeImageGeneratorRunner \ -imagecp \ /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar:/graalvm-0.30.1/jre/lib/svm/library-support.jar:/graalvm-0.30.1/examples/native-image \ -H:Path=. \ -H:InspectServerContentPath=/graalvm-0.30.1/jre/lib/svm/inspect \ -H:CLibraryPath=/graalvm-0.30.1/jre/lib/svm/clibraries/linux-amd64 \ -H:Class=HelloWorld \ -H:Name=helloworld ] classlist: 1,719.68 ms (cap): 740.90 ms setup: 987.63 ms error: Error compiling query code (in /tmp/SVM-5871999628125146202/PosixDirectives.c). Compiler command gcc /tmp/SVM-5871999628125146202/PosixDirectives.c -o /tmp/SVM-5871999628125146202/PosixDirectives output included error: /tmp/SVM-5871999628125146202/PosixDirectives.c:51:18: fatal error: zlib.h: No such file or directory C file contents around line 51: /tmp/SVM-5871999628125146202/PosixDirectives.c:50: #include /tmp/SVM-5871999628125146202/PosixDirectives.c:51: #include /tmp/SVM-5871999628125146202/PosixDirectives.c:52: #include Error: Image building with exit status 1 On Tue, Dec 12, 2017 at 2:14 AM Codrut Stancu wrote: > Hi Leonardo, > > We released a new version (graalvm-0.30.1) that fixes the NPE. The NPE > was thrown on an exception path and was hiding the real reason for the > crash that you reported. We were able to determine that from the trace > that you provided, however, we were not able to reproduce the crash. > Please download the new binaries and run the examples again. You will > most likely encounter the exception that was hidden by the NPE and that > should take us one step closer. > > Regards, > Codrut Stancu > > On Tue, 2017-12-05 at 15:33 +0000, Leonardo Loch Zanivan wrote: > > Hi, > > > > native-image not working on my Linux, even with HelloWorld sample. > > > > *$ native-image -verbose HelloWorld* > > > > Executing [ > > /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ > > -server \ > > -XX:+UnlockExperimentalVMOptions \ > > -XX:+EnableJVMCI \ > > -XX:-UseJVMCIClassLoader \ > > -XX:+UseJVMCICompiler \ > > -Dgraal.CompileGraalWithC1Only=false \ > > -d64 \ > > -noverify \ > > -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/boot/graaljs- > > scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/boot/graal-sdk.jar > > \ > > -cp \ > > /home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/svm- > > enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/jvmci- > > hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/enterprise- > > graal.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/graal.jar > > \ > > -Duser.country=US \ > > -Duser.language=en \ > > -Dgraal.EagerSnippets=true \ > > -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ > > -Dgraalvm.version=0.30 \ > > -Dorg.graalvm.version=0.30 \ > > -Xms1G \ > > -Xss10m \ > > -Dcom.oracle.graalvm.isaot=true \ > > com.oracle.svm.hosted.NativeImageGeneratorRunner \ > > -imagecp \ > > /home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/svm- > > enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/jvmci- > > hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/enterprise- > > graal.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/library- > > support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native- > > image > > \ > > -H:Path=. \ > > -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/inspect > > \ > > -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm- > > 0.30/jre/lib/svm/clibraries/linux-amd64 > > \ > > -H:Class=HelloWorld \ > > -H:Name=helloworld > > ] > > classlist: 1,800.75 ms > > (cap): 486.01 ms > > setup: 826.72 ms > > fatal error: java.lang.NullPointerException > > at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) > > at > > com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImage > > Generator.java:642) > > at > > com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.ja > > va:39) > > at > > com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator > > .java:642) > > at > > com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.j > > ava:349) > > at > > com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeIma > > geGeneratorRunner.java:221) > > at > > com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGen > > eratorRunner.java:312) > > at > > com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGene > > ratorRunner.java:58) > > Error: Image building with exit status 1 > > > > Environment: > > Ubuntu 16.10 on VirtualBox > > Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 > > UTC 2017 > > x86_64 x86_64 x86_64 GNU/Linux > From gilles.m.duboscq at oracle.com Tue Dec 12 15:03:12 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Tue, 12 Dec 2017 16:03:12 +0100 Subject: graalvm-0.30 native-image NPE on Linux In-Reply-To: References: <1513051523.16135.8.camel@oracle.com> Message-ID: <56821eb2-81bd-ff6c-92b6-3ec5b5943dab@oracle.com> Hi Leonardo, Maybe you need to install the `zlib-devel` package or equivalent for your distribution (i think `zlib1g-dev` on Ubuntu). Gilles On 12/12/17 15:10, Leonardo Loch Zanivan wrote: > Hi Codrut, > > You were right, after trying HelloWorld example with the latest build I got > the following error: > > $ native-image -verbose HelloWorld > Executing [ > /graalvm-0.30.1/jre/bin/java \ > -server \ > -XX:+UnlockExperimentalVMOptions \ > -XX:+EnableJVMCI \ > -XX:-UseJVMCIClassLoader \ > -XX:+UseJVMCICompiler \ > -Dgraal.CompileGraalWithC1Only=false \ > -d64 \ > -noverify \ > -Xbootclasspath/a:/graalvm-0.30.1/jre/lib/boot/graaljs-scriptengine.jar:/graalvm-0.30.1/jre/lib/boot/graal-sdk.jar > \ > -cp \ > /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar > \ > -Duser.country=US \ > -Duser.language=en \ > -Dgraal.EagerSnippets=true \ > -Dsubstratevm.version=2b30530bbcf4c190cd9bbdb941b7f2a9fcf66e8e \ > -Dgraalvm.version=0.30.1 \ > -Dorg.graalvm.version=0.30.1 \ > -Xms1G \ > -Xss10m \ > -Dcom.oracle.graalvm.isaot=true \ > com.oracle.svm.hosted.NativeImageGeneratorRunner \ > -imagecp \ > /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar:/graalvm-0.30.1/jre/lib/svm/library-support.jar:/graalvm-0.30.1/examples/native-image > \ > -H:Path=. \ > -H:InspectServerContentPath=/graalvm-0.30.1/jre/lib/svm/inspect \ > -H:CLibraryPath=/graalvm-0.30.1/jre/lib/svm/clibraries/linux-amd64 \ > -H:Class=HelloWorld \ > -H:Name=helloworld > ] > classlist: 1,719.68 ms > (cap): 740.90 ms > setup: 987.63 ms > error: Error compiling query code (in > /tmp/SVM-5871999628125146202/PosixDirectives.c). Compiler command gcc > /tmp/SVM-5871999628125146202/PosixDirectives.c -o > /tmp/SVM-5871999628125146202/PosixDirectives output included error: > /tmp/SVM-5871999628125146202/PosixDirectives.c:51:18: fatal error: zlib.h: > No such file or directory > C file contents around line 51: > /tmp/SVM-5871999628125146202/PosixDirectives.c:50: #include > /tmp/SVM-5871999628125146202/PosixDirectives.c:51: #include > /tmp/SVM-5871999628125146202/PosixDirectives.c:52: #include > > Error: Image building with exit status 1 > > > On Tue, Dec 12, 2017 at 2:14 AM Codrut Stancu > wrote: > >> Hi Leonardo, >> >> We released a new version (graalvm-0.30.1) that fixes the NPE. The NPE >> was thrown on an exception path and was hiding the real reason for the >> crash that you reported. We were able to determine that from the trace >> that you provided, however, we were not able to reproduce the crash. >> Please download the new binaries and run the examples again. You will >> most likely encounter the exception that was hidden by the NPE and that >> should take us one step closer. >> >> Regards, >> Codrut Stancu >> >> On Tue, 2017-12-05 at 15:33 +0000, Leonardo Loch Zanivan wrote: >>> Hi, >>> >>> native-image not working on my Linux, even with HelloWorld sample. >>> >>> *$ native-image -verbose HelloWorld* >>> >>> Executing [ >>> /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ >>> -server \ >>> -XX:+UnlockExperimentalVMOptions \ >>> -XX:+EnableJVMCI \ >>> -XX:-UseJVMCIClassLoader \ >>> -XX:+UseJVMCICompiler \ >>> -Dgraal.CompileGraalWithC1Only=false \ >>> -d64 \ >>> -noverify \ >>> -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/boot/graaljs- >>> scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/boot/graal-sdk.jar >>> \ >>> -cp \ >>> /home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/svm- >>> enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/jvmci- >>> hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/enterprise- >>> graal.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/graal.jar >>> \ >>> -Duser.country=US \ >>> -Duser.language=en \ >>> -Dgraal.EagerSnippets=true \ >>> -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ >>> -Dgraalvm.version=0.30 \ >>> -Dorg.graalvm.version=0.30 \ >>> -Xms1G \ >>> -Xss10m \ >>> -Dcom.oracle.graalvm.isaot=true \ >>> com.oracle.svm.hosted.NativeImageGeneratorRunner \ >>> -imagecp \ >>> /home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/svm- >>> enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/jvmci- >>> hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/enterprise- >>> graal.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/library- >>> support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native- >>> image >>> \ >>> -H:Path=. \ >>> -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/inspect >>> \ >>> -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm- >>> 0.30/jre/lib/svm/clibraries/linux-amd64 >>> \ >>> -H:Class=HelloWorld \ >>> -H:Name=helloworld >>> ] >>> classlist: 1,800.75 ms >>> (cap): 486.01 ms >>> setup: 826.72 ms >>> fatal error: java.lang.NullPointerException >>> at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) >>> at >>> com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImage >>> Generator.java:642) >>> at >>> com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.ja >>> va:39) >>> at >>> com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator >>> .java:642) >>> at >>> com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.j >>> ava:349) >>> at >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeIma >>> geGeneratorRunner.java:221) >>> at >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGen >>> eratorRunner.java:312) >>> at >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGene >>> ratorRunner.java:58) >>> Error: Image building with exit status 1 >>> >>> Environment: >>> Ubuntu 16.10 on VirtualBox >>> Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 >>> UTC 2017 >>> x86_64 x86_64 x86_64 GNU/Linux >> From leonardo.zanivan at gmail.com Tue Dec 12 15:14:30 2017 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 12 Dec 2017 15:14:30 +0000 Subject: graalvm-0.30 native-image NPE on Linux In-Reply-To: <56821eb2-81bd-ff6c-92b6-3ec5b5943dab@oracle.com> References: <1513051523.16135.8.camel@oracle.com> <56821eb2-81bd-ff6c-92b6-3ec5b5943dab@oracle.com> Message-ID: Thanks Gilles! Installed 'zlib1g-dev' package and everything is working now. On Tue, Dec 12, 2017 at 1:08 PM Gilles Duboscq wrote: > Hi Leonardo, > > Maybe you need to install the `zlib-devel` package or equivalent for your > distribution (i think `zlib1g-dev` on Ubuntu). > > Gilles > > On 12/12/17 15:10, Leonardo Loch Zanivan wrote: > > Hi Codrut, > > > > You were right, after trying HelloWorld example with the latest build I > got > > the following error: > > > > $ native-image -verbose HelloWorld > > Executing [ > > /graalvm-0.30.1/jre/bin/java \ > > -server \ > > -XX:+UnlockExperimentalVMOptions \ > > -XX:+EnableJVMCI \ > > -XX:-UseJVMCIClassLoader \ > > -XX:+UseJVMCICompiler \ > > -Dgraal.CompileGraalWithC1Only=false \ > > -d64 \ > > -noverify \ > > > -Xbootclasspath/a:/graalvm-0.30.1/jre/lib/boot/graaljs-scriptengine.jar:/graalvm-0.30.1/jre/lib/boot/graal-sdk.jar > > \ > > -cp \ > > > /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar > > \ > > -Duser.country=US \ > > -Duser.language=en \ > > -Dgraal.EagerSnippets=true \ > > -Dsubstratevm.version=2b30530bbcf4c190cd9bbdb941b7f2a9fcf66e8e \ > > -Dgraalvm.version=0.30.1 \ > > -Dorg.graalvm.version=0.30.1 \ > > -Xms1G \ > > -Xss10m \ > > -Dcom.oracle.graalvm.isaot=true \ > > com.oracle.svm.hosted.NativeImageGeneratorRunner \ > > -imagecp \ > > > /graalvm-0.30.1/jre/lib/svm/svm.jar:/graalvm-0.30.1/jre/lib/svm/objectfile.jar:/graalvm-0.30.1/jre/lib/svm/pointsto.jar:/graalvm-0.30.1/jre/lib/svm/svm-enterprise.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-api.jar:/graalvm-0.30.1/jre/lib/jvmci/jvmci-hotspot.jar:/graalvm-0.30.1/jre/lib/jvmci/enterprise-graal.jar:/graalvm-0.30.1/jre/lib/jvmci/graal.jar:/graalvm-0.30.1/jre/lib/svm/library-support.jar:/graalvm-0.30.1/examples/native-image > > \ > > -H:Path=. \ > > -H:InspectServerContentPath=/graalvm-0.30.1/jre/lib/svm/inspect \ > > -H:CLibraryPath=/graalvm-0.30.1/jre/lib/svm/clibraries/linux-amd64 \ > > -H:Class=HelloWorld \ > > -H:Name=helloworld > > ] > > classlist: 1,719.68 ms > > (cap): 740.90 ms > > setup: 987.63 ms > > error: Error compiling query code (in > > /tmp/SVM-5871999628125146202/PosixDirectives.c). Compiler command gcc > > /tmp/SVM-5871999628125146202/PosixDirectives.c -o > > /tmp/SVM-5871999628125146202/PosixDirectives output included error: > > /tmp/SVM-5871999628125146202/PosixDirectives.c:51:18: fatal error: > zlib.h: > > No such file or directory > > C file contents around line 51: > > /tmp/SVM-5871999628125146202/PosixDirectives.c:50: #include > > > /tmp/SVM-5871999628125146202/PosixDirectives.c:51: #include > > /tmp/SVM-5871999628125146202/PosixDirectives.c:52: #include > > > > Error: Image building with exit status 1 > > > > > > On Tue, Dec 12, 2017 at 2:14 AM Codrut Stancu > > wrote: > > > >> Hi Leonardo, > >> > >> We released a new version (graalvm-0.30.1) that fixes the NPE. The NPE > >> was thrown on an exception path and was hiding the real reason for the > >> crash that you reported. We were able to determine that from the trace > >> that you provided, however, we were not able to reproduce the crash. > >> Please download the new binaries and run the examples again. You will > >> most likely encounter the exception that was hidden by the NPE and that > >> should take us one step closer. > >> > >> Regards, > >> Codrut Stancu > >> > >> On Tue, 2017-12-05 at 15:33 +0000, Leonardo Loch Zanivan wrote: > >>> Hi, > >>> > >>> native-image not working on my Linux, even with HelloWorld sample. > >>> > >>> *$ native-image -verbose HelloWorld* > >>> > >>> Executing [ > >>> /home/ubuntu/Desktop/graal/graalvm-0.30/jre/bin/java \ > >>> -server \ > >>> -XX:+UnlockExperimentalVMOptions \ > >>> -XX:+EnableJVMCI \ > >>> -XX:-UseJVMCIClassLoader \ > >>> -XX:+UseJVMCICompiler \ > >>> -Dgraal.CompileGraalWithC1Only=false \ > >>> -d64 \ > >>> -noverify \ > >>> -Xbootclasspath/a:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/boot/graaljs- > >>> scriptengine.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/boot/graal-sdk.jar > >>> \ > >>> -cp \ > >>> /home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/svm- > >>> enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/jvmci- > >>> hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/enterprise- > >>> graal.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/graal.jar > >>> \ > >>> -Duser.country=US \ > >>> -Duser.language=en \ > >>> -Dgraal.EagerSnippets=true \ > >>> -Dsubstratevm.version=4e7e677ee680676a3285352862d011c324200b57 \ > >>> -Dgraalvm.version=0.30 \ > >>> -Dorg.graalvm.version=0.30 \ > >>> -Xms1G \ > >>> -Xss10m \ > >>> -Dcom.oracle.graalvm.isaot=true \ > >>> com.oracle.svm.hosted.NativeImageGeneratorRunner \ > >>> -imagecp \ > >>> /home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/svm.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/objectfile.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/pointsto.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/svm- > >>> enterprise.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/jvmci-api.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/jvmci- > >>> hotspot.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/enterprise- > >>> graal.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/jvmci/graal.jar:/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/library- > >>> support.jar:/home/ubuntu/Desktop/graal/graalvm-0.30/examples/native- > >>> image > >>> \ > >>> -H:Path=. \ > >>> -H:InspectServerContentPath=/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/inspect > >>> \ > >>> -H:CLibraryPath=/home/ubuntu/Desktop/graal/graalvm- > >>> 0.30/jre/lib/svm/clibraries/linux-amd64 > >>> \ > >>> -H:Class=HelloWorld \ > >>> -H:Name=helloworld > >>> ] > >>> classlist: 1,800.75 ms > >>> (cap): 486.01 ms > >>> setup: 826.72 ms > >>> fatal error: java.lang.NullPointerException > >>> at com.oracle.svm.enterprise.a.i.onAnalysisExit(stripped:23) > >>> at > >>> com.oracle.svm.hosted.NativeImageGenerator.lambda$doRun$7(NativeImage > >>> Generator.java:642) > >>> at > >>> com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.ja > >>> va:39) > >>> at > >>> com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator > >>> .java:642) > >>> at > >>> com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.j > >>> ava:349) > >>> at > >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeIma > >>> geGeneratorRunner.java:221) > >>> at > >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGen > >>> eratorRunner.java:312) > >>> at > >>> com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGene > >>> ratorRunner.java:58) > >>> Error: Image building with exit status 1 > >>> > >>> Environment: > >>> Ubuntu 16.10 on VirtualBox > >>> Linux ubuntu-1 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 > >>> UTC 2017 > >>> x86_64 x86_64 x86_64 GNU/Linux > >> > From adam at cs.miami.edu Tue Dec 19 03:55:46 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Mon, 18 Dec 2017 22:55:46 -0500 Subject: graal + node.js: how does it work? Message-ID: Hi, I am interested in learning more about graal + node.js, and I am wondering how node.js is integrated into graal/jvm? Can you let me know if the following is about correct? [1] Node.js core was re-written from c++ to java (this seems to be the old avatar project??) [2] Graal.js calls into the java implementation of node for the JVM. Does the above sound correct? I am interested in how node code can run well on the JVM. I have a partial implementation that I wrote of node.js modules that are a thin JS wrapper on top of vert.x Javasscript. This approach has worked well for me (still in early stages), but I was interested on you all have implemented node.js Best, -Adam From jaroslav.tulach at oracle.com Tue Dec 19 08:52:49 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 19 Dec 2017 09:52:49 +0100 Subject: graal + node.js: how does it work? In-Reply-To: References: Message-ID: <7010357.b3TNWIGFpA@pracovni> Hello Adam, thanks for your interest in graal + node.js. I am maintaining https://github.com/graalvm/graal-js-archetype archetype. Would you find its approach useful? On pond?l? 18. prosince 2017 22:55:46 CET Adam McMahon wrote: > I am interested in learning more about graal + node.js, and I am wondering > how node.js is integrated into graal/jvm? > > Can you let me know if the following is about correct? > > [1] Node.js core was re-written from c++ to java (this seems to be the old > avatar project??) No, not at all. > [2] Graal.js calls into the java implementation of node for the JVM. Closer. > Does the above sound correct? node.js is using v8.h to perform its calls into JavaScript. Jan ?tola has reimplemented v8.h, so it calls into our (Java based) implementation of Graal.js. Except v8.h (and related) the rest of node.js code is unmodified. As such we believe we can be more compatible than original Avatar.js based solution. > I am interested in how node code can run well on the JVM. I have a partial > implementation that I wrote of node.js modules that are a thin JS wrapper > on top of vert.x Javasscript. Nice. Our group would be interested in comparing the speed - our desire is to make Java/JavaScript/node.js interop fast - faster than any other available. Good luck and let us know your graal+node.js related findings & thoughts. -jt From jan.stola at oracle.com Tue Dec 19 09:42:28 2017 From: jan.stola at oracle.com (Jan Stola) Date: Tue, 19 Dec 2017 10:42:28 +0100 Subject: graal + node.js: how does it work? In-Reply-To: References: Message-ID: <41e11344-ebef-4302-17f5-1f73cad48513@oracle.com> Hi Adam, thanks for your interest in graal-node.js. Node.js embeds V8 JavaScript engine by default. It accesses it through its API (represented by v8.h mainly). We keep all the native code of the original Node.js (almost) intact. We just replace V8 engine by our JavaScript engine (Graal.js). We do that by providing an implementation of the native V8 API. Our implementation of this API delegates to the corresponding Graal.js calls. So, the native Node.js code "thinks" that it uses V8 still but it is using Graal.js instead. Honza On 19.12.2017 4:55, Adam McMahon wrote: > Hi, > > I am interested in learning more about graal + node.js, and I am wondering > how node.js is integrated into graal/jvm? > > Can you let me know if the following is about correct? > > [1] Node.js core was re-written from c++ to java (this seems to be the old > avatar project??) > [2] Graal.js calls into the java implementation of node for the JVM. > > Does the above sound correct? > > I am interested in how node code can run well on the JVM. I have a partial > implementation that I wrote of node.js modules that are a thin JS wrapper > on top of vert.x Javasscript. This approach has worked well for me (still > in early stages), but I was interested on you all have implemented node.js > > Best, > > -Adam > From adam at cs.miami.edu Wed Dec 20 03:14:35 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Tue, 19 Dec 2017 22:14:35 -0500 Subject: graal + node.js: how does it work? In-Reply-To: <7010357.b3TNWIGFpA@pracovni> References: <7010357.b3TNWIGFpA@pracovni> Message-ID: Jaroslav, Thanks for the info. Yes, your archetype project might be useful. Thanks for the information that you have provided on how graal+node works. Your approach seems to be very good, because it does not require a constant update, assuming that v8.h does not change very often, it should be able to run the newest node. My approach, which is really just a proof of concept partially implementing a few modules, would require me to make more changes as new features are added to the core of node. I will be happy to share my code on github once I get an example together a half-decent example that works well on all 3 systems (node.js, graal+node, node+vertxWrapper). But in terms of performance, my approach runs about the same as vert.x (if you are familiar with that performance), as mine is just a thin call down to vert.x from JS. Best, -Adam On Tue, Dec 19, 2017 at 3:52 AM, Jaroslav Tulach wrote: > Hello Adam, > thanks for your interest in graal + node.js. I am maintaining > https://github.com/graalvm/graal-js-archetype > archetype. Would you find its approach useful? > > On pond?l? 18. prosince 2017 22:55:46 CET Adam McMahon wrote: > > I am interested in learning more about graal + node.js, and I am > wondering > > how node.js is integrated into graal/jvm? > > > > Can you let me know if the following is about correct? > > > > [1] Node.js core was re-written from c++ to java (this seems to be the > old > > avatar project??) > > No, not at all. > > > [2] Graal.js calls into the java implementation of node for the JVM. > > Closer. > > > Does the above sound correct? > > node.js is using v8.h to perform its calls into JavaScript. Jan ?tola has > reimplemented v8.h, so it calls into our (Java based) implementation of > Graal.js. Except v8.h (and related) the rest of node.js code is > unmodified. As > such we believe we can be more compatible than original Avatar.js based > solution. > > > I am interested in how node code can run well on the JVM. I have a > partial > > implementation that I wrote of node.js modules that are a thin JS wrapper > > on top of vert.x Javasscript. > > Nice. Our group would be interested in comparing the speed - our desire is > to > make Java/JavaScript/node.js interop fast - faster than any other > available. > > Good luck and let us know your graal+node.js related findings & thoughts. > -jt > > From ted at tedneward.com Wed Dec 20 07:54:11 2017 From: ted at tedneward.com (Ted Neward) Date: Tue, 19 Dec 2017 23:54:11 -0800 Subject: Graal in JDK10? Message-ID: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> I just started browsing around in the JDK source code (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which appears to have the GraalVM bits in it?is this planning to go out as part of JDK 10? Please? :-) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From dalibor.topic at oracle.com Wed Dec 20 08:25:31 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 20 Dec 2017 09:25:31 +0100 Subject: Graal in JDK10? In-Reply-To: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> References: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> Message-ID: See http://openjdk.java.net/jeps/317 ;) On 20.12.2017 08:54, Ted Neward wrote: > I just started browsing around in the JDK source code (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which appears to have the GraalVM bits in it?is this planning to go out as part of JDK 10? Please? :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From jaroslav.tulach at oracle.com Wed Dec 20 08:40:23 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 20 Dec 2017 09:40:23 +0100 Subject: graal + node.js: how does it work? In-Reply-To: References: <7010357.b3TNWIGFpA@pracovni> Message-ID: <12112682.obK7pvVDnE@pracovni> Hello Adam, a small note on performance: On ?ter? 19. prosince 2017 22:14:35 CET Adam McMahon wrote: > But in terms of > performance, my approach runs about the same as vert.x (if you are familiar > with that performance), as mine is just a thin call down to vert.x from JS. This would be the kind of reply I'd use before joining the Graal team. However now I have to ask: - what does a "thin call from JS" mean? - how fast the JS implementation is? First of all, from all the Java based JavaScript implementations, only Graal.js is comparable in terms of speed with V8. All other ones are significantly slower. Secondly, the "thin call from JS" may require argument mangling and possibly also inlining boundary. Again, this is something Graal + Graal.js can eliminate and make the execution faster. > ... share my code on github once I get an example together a half-decent > example that works well on all 3 systems (node.js, graal+node, node +vertxWrapper). Of course, the performance depends on the actual usage. Once your example works, it would be nice to turn it into a benchmark and measure the # of operations per second each version can handle. Good luck. -jt From jaroslav.tulach at oracle.com Wed Dec 20 08:45:39 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 20 Dec 2017 09:45:39 +0100 Subject: Graal in JDK10? In-Reply-To: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> References: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> Message-ID: <2119755.7hITYzDF9H@pracovni> On ?ter? 19. prosince 2017 23:54:11 CET Ted Neward wrote: > I just started browsing around in the JDK source code > (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which > appears to have the GraalVM bits in it?is this planning to go out as part > of JDK 10? Please? :-) Hello Ted. As far as I can tell Graal compiler is an important part of JDK9 (used for AOT compilation). With few intrinsic switches it can even be turn on and used for regular JIT compilation - find the details in the amazing Chris Seaton's article http://chrisseaton.com/rubytruffle/jokerconf17/ In addition to that Dalibor is right > See http://openjdk.java.net/jeps/317 more progress can be expected in forthcoming JDK releases. -jt From ted at tedneward.com Wed Dec 20 09:22:12 2017 From: ted at tedneward.com (Ted Neward) Date: Wed, 20 Dec 2017 01:22:12 -0800 Subject: Graal in JDK10? In-Reply-To: <2119755.7hITYzDF9H@pracovni> References: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> <2119755.7hITYzDF9H@pracovni> Message-ID: <1D3F4D98-61E9-433B-BDDC-8B6D57C7D9CE@tedneward.com> I've had the pleasure of meeting Chris in person (DevoxxUK, earlier this year or last year, IIRC), and I'm definitely going to be going over that article later. I guess what I'm leaning towards is a definitive "yes" or "no" as to whether Graal will be included as part of the *production* JDK releases, where the JEP talks about using the XX flags to turn on Experimental features, which are (probably) a non-starter for most production use scenarios, but I am willing to accept that Oracle may not know or want to commit to anything publicly at this point. That said, if it's a given that it'll ship as part of production.... that would get me to do a happy dance, for sure. :-) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 ?On 12/20/17, 12:45 AM, "Jaroslav Tulach" wrote: On ?ter? 19. prosince 2017 23:54:11 CET Ted Neward wrote: > I just started browsing around in the JDK source code > (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which > appears to have the GraalVM bits in it?is this planning to go out as part > of JDK 10? Please? :-) Hello Ted. As far as I can tell Graal compiler is an important part of JDK9 (used for AOT compilation). With few intrinsic switches it can even be turn on and used for regular JIT compilation - find the details in the amazing Chris Seaton's article http://chrisseaton.com/rubytruffle/jokerconf17/ In addition to that Dalibor is right > See http://openjdk.java.net/jeps/317 more progress can be expected in forthcoming JDK releases. -jt From volker.simonis at gmail.com Wed Dec 20 09:36:59 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Dec 2017 10:36:59 +0100 Subject: Graal in JDK10? In-Reply-To: <1D3F4D98-61E9-433B-BDDC-8B6D57C7D9CE@tedneward.com> References: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> <2119755.7hITYzDF9H@pracovni> <1D3F4D98-61E9-433B-BDDC-8B6D57C7D9CE@tedneward.com> Message-ID: Hi Ted, you may want to visit the Java dev room at FOSDEM (https://fosdem.org/2018/schedule/track/free_java/) and listen to Christian Thalingers talk. They are using Graal productively at Twitter for a while now. Regards, Volker On Wed, Dec 20, 2017 at 10:22 AM, Ted Neward wrote: > I've had the pleasure of meeting Chris in person (DevoxxUK, earlier this year or last year, IIRC), and I'm definitely going to be going over that article later. > > I guess what I'm leaning towards is a definitive "yes" or "no" as to whether Graal will be included as part of the *production* JDK releases, where the JEP talks about using the XX flags to turn on Experimental features, which are (probably) a non-starter for most production use scenarios, but I am willing to accept that Oracle may not know or want to commit to anything publicly at this point. > > That said, if it's a given that it'll ship as part of production.... that would get me to do a happy dance, for sure. :-) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > ?On 12/20/17, 12:45 AM, "Jaroslav Tulach" wrote: > > On ?ter? 19. prosince 2017 23:54:11 CET Ted Neward wrote: > > I just started browsing around in the JDK source code > > (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which > > appears to have the GraalVM bits in it?is this planning to go out as part > > of JDK 10? Please? :-) > > Hello Ted. > As far as I can tell Graal compiler is an important part of JDK9 (used for AOT > compilation). With few intrinsic switches it can even be turn on and used for > regular JIT compilation - find the details in the amazing Chris Seaton's > article http://chrisseaton.com/rubytruffle/jokerconf17/ > > In addition to that Dalibor is right > > > See http://openjdk.java.net/jeps/317 > > more progress can be expected in forthcoming JDK releases. > -jt > > > > > From cthalinger at twitter.com Wed Dec 20 17:49:11 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 20 Dec 2017 12:49:11 -0500 Subject: Graal in JDK10? In-Reply-To: References: <14DDC6F8-1287-4DE5-87DA-2F56F8DA866B@tedneward.com> <2119755.7hITYzDF9H@pracovni> <1D3F4D98-61E9-433B-BDDC-8B6D57C7D9CE@tedneward.com> Message-ID: <884690F3-2E0F-4442-A075-599D40E0DAE1@twitter.com> > On Dec 20, 2017, at 4:36 AM, Volker Simonis wrote: > > Hi Ted, > > you may want to visit the Java dev room at FOSDEM > (https://fosdem.org/2018/schedule/track/free_java/) and listen to > Christian Thalingers talk. They are using Graal productively at > Twitter for a while now. Very productively, I?d like to add :-) > > Regards, > Volker > > > On Wed, Dec 20, 2017 at 10:22 AM, Ted Neward wrote: >> I've had the pleasure of meeting Chris in person (DevoxxUK, earlier this year or last year, IIRC), and I'm definitely going to be going over that article later. >> >> I guess what I'm leaning towards is a definitive "yes" or "no" as to whether Graal will be included as part of the *production* JDK releases, where the JEP talks about using the XX flags to turn on Experimental features, which are (probably) a non-starter for most production use scenarios, but I am willing to accept that Oracle may not know or want to commit to anything publicly at this point. >> >> That said, if it's a given that it'll ship as part of production.... that would get me to do a happy dance, for sure. :-) >> >> Ted Neward >> Author, Speaker, Mentor >> http://www.newardassociates.com >> t: @tedneward | m: (425) 647-4526 >> >> ?On 12/20/17, 12:45 AM, "Jaroslav Tulach" wrote: >> >> On ?ter? 19. prosince 2017 23:54:11 CET Ted Neward wrote: >>> I just started browsing around in the JDK source code >>> (hg.openjdk.java.net/jdk/jdk) and found jdk.internal.vm.compiler, which >>> appears to have the GraalVM bits in it?is this planning to go out as part >>> of JDK 10? Please? :-) >> >> Hello Ted. >> As far as I can tell Graal compiler is an important part of JDK9 (used for AOT >> compilation). With few intrinsic switches it can even be turn on and used for >> regular JIT compilation - find the details in the amazing Chris Seaton's >> article http://chrisseaton.com/rubytruffle/jokerconf17/ >> >> In addition to that Dalibor is right >> >>> See http://openjdk.java.net/jeps/317 >> >> more progress can be expected in forthcoming JDK releases. >> -jt >> >> >> >> >> From adam at cs.miami.edu Sat Dec 23 21:21:25 2017 From: adam at cs.miami.edu (Adam McMahon) Date: Sat, 23 Dec 2017 16:21:25 -0500 Subject: graal + node.js: how does it work? In-Reply-To: <12112682.obK7pvVDnE@pracovni> References: <7010357.b3TNWIGFpA@pracovni> <12112682.obK7pvVDnE@pracovni> Message-ID: Jaroslav and group, I had a chance to run some tests running node.js on the JVM using the Vert.x library. I call this project node.v (node running on vert.x). Included are some benchmarks of my approach vs graal-node and native node. *[1] node.v* Project is found at https://github.com/AdamMcM/node.v (the readme has setup instructions if anyone is interested). Vert.x is a polyglot inspired node library for the JVM that has many features similar to node already written in Javascript using Nashorn. For most of the functionality in Node, One can implement node.js by writing a small wrapper that calls down to the JS Vert.x API. For example, Vert.x already has a method called readFile which is very similar to node?s fs.readFile: https://github.com/AdamMcM/node.v/blob/master/fs.js *[2] Performance* Take this all with a grain of salt :) In the two examples I ran, Node.v is almost as performant as native node.js, and it is significantly faster than graal?s node implementation. In fact, graal-node runs so much slower than native node that I am wondering if I have a setup issue. Based on Devoxx presentations, I was expecting it to be near native node performance. Here are some benchmarks. *[2a] HelloWorld. * https://github.com/AdamMcM/node.v/blob/master/helloTest.js 10 concurrent clients, Node.v is the fastest, with graal-native the slowest. *Node.v x3* indictes that 3 instnces of vert.x were used. This is similar to node?s cluster module, but does not require any change to the script, just adding ?-?instances 3? to the command line, it will automatically scale to 3 event loops. No other code changes are necessary. numbers are in requests per second node.v x3: 14182 (long jvm warmup: 100k requests) node.v : 10103 (long jvm warmup) node9: 8172 node-graal-jvm: 5065 (long jvm warmup) node-graal-native: 4101 [2a] FileTest https://github.com/AdamMcM/node.v/blob/master/fileTest.js Read a small file, 36 bytes, and send it back to the client 10 times using chunked encoding. Node9 3593 node.v x3: 3354 (after long warm up) node.v : 1900 (after long warm up) node-graal-native: 228 node-graal-jvm: 228 *[3] Discussion* Node.v is a small proof of concept that node.js can be relatively easily implemented onto the JVM using the Vert.x library. To do so, one can create wrapper functions down to the Javascript Vert.x API. Unless there was a setup issue, node.v is significantly faster than node-graal in these examples. Node.v uses Nashorn, perhaps it could be improved even more by using graal.js instead. This was just a proof of concept project for me to learn more about node.js on the JVM, I will likely add a few more examples and flush out a few more features, but I do not intend (at this time) to implement the entire node.js API (as my day job keeps me pretty busy). Best and Happy Holidays, -Adam On Wed, Dec 20, 2017 at 3:40 AM, Jaroslav Tulach wrote: > Hello Adam, > a small note on performance: > > On ?ter? 19. prosince 2017 22:14:35 CET Adam McMahon wrote: > > But in terms of > > performance, my approach runs about the same as vert.x (if you are > familiar > > with that performance), as mine is just a thin call down to vert.x from > JS. > > This would be the kind of reply I'd use before joining the Graal team. > However > now I have to ask: > > - what does a "thin call from JS" mean? > - how fast the JS implementation is? > > First of all, from all the Java based JavaScript implementations, only > Graal.js is comparable in terms of speed with V8. All other ones are > significantly slower. Secondly, the "thin call from JS" may require > argument > mangling and possibly also inlining boundary. Again, this is something > Graal + > Graal.js can eliminate and make the execution faster. > > > ... share my code on github once I get an example together a half-decent > > example that works well on all 3 systems (node.js, graal+node, node > +vertxWrapper). > > Of course, the performance depends on the actual usage. Once your example > works, it would be nice to turn it into a benchmark and measure the # of > operations per second each version can handle. > > Good luck. > -jt > > From mrgranthaywood at gmail.com Sun Dec 24 00:17:39 2017 From: mrgranthaywood at gmail.com (Grant Haywood) Date: Sun, 24 Dec 2017 00:17:39 +0000 Subject: graal + node.js: how does it work? In-Reply-To: References: <7010357.b3TNWIGFpA@pracovni> <12112682.obK7pvVDnE@pracovni> Message-ID: Am I mistaken but isint the point of graal/node to be able to access c++ based node modules? Fwiw id love to see support for native node modules in vert.x through graal. On Dec 23, 2017 9:21 PM, "Adam McMahon" wrote: Jaroslav and group, I had a chance to run some tests running node.js on the JVM using the Vert.x library. I call this project node.v (node running on vert.x). Included are some benchmarks of my approach vs graal-node and native node. *[1] node.v* Project is found at https://github.com/AdamMcM/node.v (the readme has setup instructions if anyone is interested). Vert.x is a polyglot inspired node library for the JVM that has many features similar to node already written in Javascript using Nashorn. For most of the functionality in Node, One can implement node.js by writing a small wrapper that calls down to the JS Vert.x API. For example, Vert.x already has a method called readFile which is very similar to node?s fs.readFile: https://github.com/AdamMcM/node.v/blob/master/fs.js *[2] Performance* Take this all with a grain of salt :) In the two examples I ran, Node.v is almost as performant as native node.js, and it is significantly faster than graal?s node implementation. In fact, graal-node runs so much slower than native node that I am wondering if I have a setup issue. Based on Devoxx presentations, I was expecting it to be near native node performance. Here are some benchmarks. *[2a] HelloWorld. * https://github.com/AdamMcM/node.v/blob/master/helloTest.js 10 concurrent clients, Node.v is the fastest, with graal-native the slowest. *Node.v x3* indictes that 3 instnces of vert.x were used. This is similar to node?s cluster module, but does not require any change to the script, just adding ?-?instances 3? to the command line, it will automatically scale to 3 event loops. No other code changes are necessary. numbers are in requests per second node.v x3: 14182 (long jvm warmup: 100k requests) node.v : 10103 (long jvm warmup) node9: 8172 node-graal-jvm: 5065 (long jvm warmup) node-graal-native: 4101 [2a] FileTest https://github.com/AdamMcM/node.v/blob/master/fileTest.js Read a small file, 36 bytes, and send it back to the client 10 times using chunked encoding. Node9 3593 node.v x3: 3354 (after long warm up) node.v : 1900 (after long warm up) node-graal-native: 228 node-graal-jvm: 228 *[3] Discussion* Node.v is a small proof of concept that node.js can be relatively easily implemented onto the JVM using the Vert.x library. To do so, one can create wrapper functions down to the Javascript Vert.x API. Unless there was a setup issue, node.v is significantly faster than node-graal in these examples. Node.v uses Nashorn, perhaps it could be improved even more by using graal.js instead. This was just a proof of concept project for me to learn more about node.js on the JVM, I will likely add a few more examples and flush out a few more features, but I do not intend (at this time) to implement the entire node.js API (as my day job keeps me pretty busy). Best and Happy Holidays, -Adam On Wed, Dec 20, 2017 at 3:40 AM, Jaroslav Tulach wrote: > Hello Adam, > a small note on performance: > > On ?ter? 19. prosince 2017 22:14:35 CET Adam McMahon wrote: > > But in terms of > > performance, my approach runs about the same as vert.x (if you are > familiar > > with that performance), as mine is just a thin call down to vert.x from > JS. > > This would be the kind of reply I'd use before joining the Graal team. > However > now I have to ask: > > - what does a "thin call from JS" mean? > - how fast the JS implementation is? > > First of all, from all the Java based JavaScript implementations, only > Graal.js is comparable in terms of speed with V8. All other ones are > significantly slower. Secondly, the "thin call from JS" may require > argument > mangling and possibly also inlining boundary. Again, this is something > Graal + > Graal.js can eliminate and make the execution faster. > > > ... share my code on github once I get an example together a half-decent > > example that works well on all 3 systems (node.js, graal+node, node > +vertxWrapper). > > Of course, the performance depends on the actual usage. Once your example > works, it would be nice to turn it into a benchmark and measure the # of > operations per second each version can handle. > > Good luck. > -jt > > From thomas.wuerthinger at oracle.com Sun Dec 24 11:06:00 2017 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sun, 24 Dec 2017 12:06:00 +0100 Subject: graal + node.js: how does it work? In-Reply-To: References: <7010357.b3TNWIGFpA@pracovni> <12112682.obK7pvVDnE@pracovni> Message-ID: Yes, it supports native node.js modules and is 100% compatible with the V8-based node.js. So it can run all node.js modules. It would indeed be interesting to run Graal in the context of vert.x. We will check the benchmarks after the holidays. Cheers, thomas > On 24 Dec 2017, at 01:17, Grant Haywood wrote: > > Am I mistaken but isint the point of graal/node to be able to access c++ > based node modules? > Fwiw id love to see support for native node modules in vert.x through > graal. > > On Dec 23, 2017 9:21 PM, "Adam McMahon" wrote: > > Jaroslav and group, > > I had a chance to run some tests running node.js on the JVM using the > Vert.x library. I call this project node.v (node running on vert.x). > Included are some benchmarks of my approach vs graal-node and native node. > > *[1] node.v* > > Project is found at https://github.com/AdamMcM/node.v (the readme has setup > instructions if anyone is interested). > > Vert.x is a polyglot inspired node library for the JVM that has many > features similar to node already written in Javascript using Nashorn. For > most of the functionality in Node, One can implement node.js by writing a > small wrapper that calls down to the JS Vert.x API. For example, Vert.x > already has a method called readFile which is very similar to node?s > fs.readFile: https://github.com/AdamMcM/node.v/blob/master/fs.js > > > *[2] Performance* > > Take this all with a grain of salt :) > > In the two examples I ran, Node.v is almost as performant as native > node.js, and it is significantly faster than graal?s node implementation. > In fact, graal-node runs so much slower than native node that I am > wondering if I have a setup issue. Based on Devoxx presentations, I was > expecting it to be near native node performance. > > Here are some benchmarks. > > *[2a] HelloWorld. * > https://github.com/AdamMcM/node.v/blob/master/helloTest.js > > 10 concurrent clients, Node.v is the fastest, with graal-native the > slowest. *Node.v x3* indictes that 3 instnces of vert.x were used. This is > similar to node?s cluster module, but does not require any change to the > script, just adding ?-?instances 3? to the command line, it will > automatically scale to 3 event loops. No other code changes are necessary. > > numbers are in requests per second > > node.v x3: 14182 (long jvm warmup: 100k requests) > node.v : 10103 (long jvm warmup) > node9: 8172 > node-graal-jvm: 5065 (long jvm warmup) > node-graal-native: 4101 > > [2a] FileTest https://github.com/AdamMcM/node.v/blob/master/fileTest.js > > Read a small file, 36 bytes, and send it back to the client 10 times using > chunked encoding. > > Node9 3593 > node.v x3: 3354 (after long warm up) > node.v : 1900 (after long warm up) > node-graal-native: 228 > node-graal-jvm: 228 > > > *[3] Discussion* > > Node.v is a small proof of concept that node.js can be relatively easily > implemented onto the JVM using the Vert.x library. To do so, one can create > wrapper functions down to the Javascript Vert.x API. Unless there was a > setup issue, node.v is significantly faster than node-graal in these > examples. Node.v uses Nashorn, perhaps it could be improved even more by > using graal.js instead. > > This was just a proof of concept project for me to learn more about node.js > on the JVM, I will likely add a few more examples and flush out a few more > features, but I do not intend (at this time) to implement the entire > node.js API (as my day job keeps me pretty busy). > > Best and Happy Holidays, > > -Adam > > > > > > On Wed, Dec 20, 2017 at 3:40 AM, Jaroslav Tulach > wrote: > >> Hello Adam, >> a small note on performance: >> >> On ?ter? 19. prosince 2017 22:14:35 CET Adam McMahon wrote: >>> But in terms of >>> performance, my approach runs about the same as vert.x (if you are >> familiar >>> with that performance), as mine is just a thin call down to vert.x from >> JS. >> >> This would be the kind of reply I'd use before joining the Graal team. >> However >> now I have to ask: >> >> - what does a "thin call from JS" mean? >> - how fast the JS implementation is? >> >> First of all, from all the Java based JavaScript implementations, only >> Graal.js is comparable in terms of speed with V8. All other ones are >> significantly slower. Secondly, the "thin call from JS" may require >> argument >> mangling and possibly also inlining boundary. Again, this is something >> Graal + >> Graal.js can eliminate and make the execution faster. >> >>> ... share my code on github once I get an example together a half-decent >>> example that works well on all 3 systems (node.js, graal+node, node >> +vertxWrapper). >> >> Of course, the performance depends on the actual usage. Once your example >> works, it would be nice to turn it into a benchmark and measure the # of >> operations per second each version can handle. >> >> Good luck. >> -jt >> >> From mail2leoj at gmail.com Mon Dec 25 01:25:10 2017 From: mail2leoj at gmail.com (Joel Buckley) Date: Sun, 24 Dec 2017 18:25:10 -0700 Subject: Is intent to *check* or *set* assertions? Message-ID: <91706DE0-A0A1-45C0-B313-060FA9D684A9@gmail.com> Hi Graal-dev, In Substrate-Util.java[1], is the intent to *check* and/or *set* assertions to *true*? /** * Checks whether assertions are enabled in the VM. * * @return true if assertions are enabled. */ @SuppressWarnings("all") public static boolean assertionsEnabled() { boolean assertionsEnabled = false; assert assertionsEnabled = true; // should this be ?== true?? return assertionsEnabled; // Otherwise, this is always true... } Thanks, Joel. [1]https://github.com/graalvm/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/SubstrateUtil.java From codrut.stancu at oracle.com Mon Dec 25 03:58:46 2017 From: codrut.stancu at oracle.com (Codrut Stancu) Date: Sun, 24 Dec 2017 19:58:46 -0800 Subject: Is intent to *check* or *set* assertions? Message-ID: <201712250359.vBP3x1V5030488@aserv0122.oracle.com> The code is correct. The method returns true if assertions are enabled, false otherwise. If assertions are enabled then the "assert assertionsEnabled = true" line is executed and sets the variable to true, which also causes the assertion check to pass. If assertions are disabled then the "assert assertionsEnabled = true" line is never executed, so the variable remains false. Thus the intent of this method is to answer the question: "Are the assertions enabled?". Codrut Stancu On Dec 24, 2017 5:25 PM, Joel Buckley wrote: > > Hi Graal-dev, > > In Substrate-Util.java[1], is the intent to *check* and/or *set* assertions to *true*? > > > ??? /** > ???? * Checks whether assertions are enabled in the VM. > ???? * > ???? * @return true if assertions are enabled. > ???? */ > ??? @SuppressWarnings("all") > ??? public static boolean assertionsEnabled() { > ??????? boolean assertionsEnabled = false; > ??????? assert assertionsEnabled = true; // should this be ?== true?? > ??????? return assertionsEnabled; // Otherwise, this is always true... > ??? } > > > Thanks, > Joel. > > [1]https://github.com/graalvm/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/SubstrateUtil.java >