GraalVM: The holy graal of polyglot JVM? | Hacker News Reader

GraalVM: The holy graal of polyglot JVM?

transposit.com

157 pointsmooreds45 comments

Supposedly es4x (powered by GraalVM) cracked the top-5 empower benchmarks, while no other Node/JS frameworks are in top-20/top-30 (iirc):

https://www.youtube.com/watch?v=JUJ85k3aEg4

The assertion in the ^ video (from the es4x author) is that node programs hop across the http/libuv/v8/etc. boundaries all the time, and that's the majority of the overhead, not actual business/program logic.

So, es4x sitting on graal brings all of those http/event loop/js runtime infra projects into a single optimizing VM.

My memory is ~fuzy on the details, but I believe I got our apollo server running running on es4x a few months back, and the latency was ~double node, which was still impressive IMO, but I didn't see the amazing gains that the author does. Not sure why.

the author of [1] basically says the same thing. in terms of io/throughput you gotta side-step Node (but v8 itself is plenty fast).

he's famous for trolling the Node & Deno repos (i think he's banned from both). he also refuses to participate in the benchmarks (despite being able to score very well) because he says their methodology is flawed.

[1] https://github.com/uNetworking/uWebSockets.js/

I integrated a really simple JS runtime into a C# project once and found the same thing. V8 was orders of magnitude slower due to the interop overhead. Even though the IronJS compiler was very simplistic it was just so much faster to do it inside the CLR and let the MSIL JIT optimize to the degree it was able. An example of “worse is better” I suppose.

I'd say it's an example of optimizing the right thing. Business code is relatively short and uncomplicated, compared to the interop code. So optimizing the slowest part (but not the most obvious part) gave good results.

JS inside C# being faster than Node is great news!

Just like Google did with their FloatMath class, after Dalvik got replaced by a proper JIT compiler.

https://developer.android.com/reference/android/util/FloatMa...

AIUI, es4x essentially replaces Node with Eclipse Vert.x, so the main question for me is how it compares to running on a normal JVM. Do you have any figures there?

It does work on a stock openjdk11 with similar performance (but I don't have numbers to show). What happens in this case is that we can load the graal compiler to replace the default jit but it will not allow you to use other languages as only graaljs currently runs on this mode.

Hi, I'm the author of ES4X I'd love to check your graphql test. I've no experience on Apollo so if you could share a test/benchmark it would be great to see where the bottlenecks come from.

Clojure "Hello, world" compiled with Graal running in Docker wasn't that bad: https://gist.github.com/cellularmitosis/66e024439cdefbc43375...

Have you tried to build anything larger with Graal/Clojure?

I'm not GP, but we have done several native Clojure CLI apps with Graal:

https://github.com/latacora/wernicke

https://github.com/latacora/recidiffist-cli

https://github.com/latacora/caro

As well as several internal tools. It mostly works fine. Graal is actually the default JDK on my development machine.

If there's one thing I'd fix, it's the ability to bake dylibs into the single binaries. E.g. if you want good elliptic curve TLS, you need sunec.so/dylib/dll, and part of the point for native-image for us is the ability to ship a single binary.

I tried and failed to build a “hello world” http server using aleph.

Not me, but the small CLI utilities form Michiel Borkent are pretty interesting:

- https://github.com/borkdude/clj-kondo

- https://github.com/borkdude/sci

- https://github.com/borkdude/babashka

Oh, cool! I tested clojure and graal some months back and, at the time, it was a lot clunkier to get working and only worked with clojure 1.9. This looks much simpler and works with 1.10, awesome!

Did you compare the GraalVM compiler with the open-source jaotc (java ahead of time compiler tool, from Java 9) ?

Jaotc is based on graalvm

Watch out if you choose the "enterprise" version; you can't use it for development of an app that will be used in production.

Indeed you need to buy the enterprise version for use in production. This is funding the project so that the majority of the features can stay open source.

This is good advice, you don't want to find yourself in a lawsuit with Oracle.

Until GraalJS can get even close to native JS VMs in performance, I still think of it as Java VM.

https://github.com/graalvm/graaljs/issues/74

Maybe I am reading that issue incorrectly, but it seemed there was some back and forth on startup time penalties and what constituted a valid benchmark to compare the two systems.

If what they just wanted was ES6 syntax, why not use Babel? But I guess what they really wanted was to get off of their deprecated JS runtime (Nashorn).

Great to see GraalJS is a realistic option. This polyglot VM idea is fascinating, though it's not likely to go anywhere for my personal use until GraalVM Python gets some traction. I check in on it now and then - every time it hits HN - but it seems to be going nowhere. Anyone have any experience with that?

GraalVM Community is GPLv2 with no support.[0]

GraalVM Enterprise costs $18/mo/core[1]. Every machine running GE needs a license so a 16-core production server, 4-core staging box and 4-core dev laptop will cost you $18*24 = $432/mo.

[0]: https://www.graalvm.org/docs/faq/ [1]: https://www.oracle.com/uk/a/ocom/docs/corporate/pricing/graa...

According to your first source, GraalVM

> is free for testing, evaluation, or for developing non-production applications

This means that the price model is, perhaps unsurprisingly, close to the OracleJava one.

I found this helpful for getting going with OpenJDK 8/Graal on Mac OS X (but the instructions are highly applicable to Linux as well).

https://blog.softwaremill.com/graalvm-installation-and-setup...

There is a brew cask now: https://github.com/DeLaGuardo/homebrew-graalvm

Mind me asking some questions here?

(openjdk 8)

Do you need to install graalvm separately on the target system, or can the compiler and runtime be packaged with the application in the uberjar?

Do you need to change the the java execution command line to enable graalvm?

Does end user need to know anything about truffle or is it api for language developers?

GraalVM has several parts. If you want to run polyglot apps directly, yes, you need to install GraalVM. If you compile your JVM apps to native, no, you get a standalone binary.

Truffle is a developer-facing API.

I am still dreaming on Ruby, C extension, Rails, along with Javascript bundling all running solely on GraalVM and nothing else.

Although Chris Seaton is no longer working on TruffleRuby, so I guess this isn't going to happen anytime soon.

Don't worry TruffleRuby has a strong team that is dedicated to deliver. Besides, Chris is still working on TruffleRuby in his new role.

> Although Chris Seaton is no longer working on TruffleRuby

I’m still working with TruffleRuby, just at Shopify instead of Oracle.

It needs to support wasm on the front and the back, as well as RISC-V on the back (and maybe on the front). When it does those things, it will be The Ring.

WASM: https://github.com/oracle/graal/issues/1358

Wasn't able to find anything about RISC-V, file an issue :)

I don't get it. Seems like a lot of overhead.

Sorry, what do you mean?

Bloated JVMs are not worth the trouble. Especially with containers...

The whole point of this is that it isn’t a bloated VM - it’s compiled to native. It works really well with containers.

Containers are catching up with features that bloated JVM have had for years, without their monitoring and debugging capabilities in production.

We still don't see any business need to bother with containers, other that being trendy and fashionable.

GraalVM/SubstrateVM will compile to native ONLY the code which is being used. So the native executable is MUCH LESS bloated than the JAR running on regular JVM.

Customers running js on your server in a Java VM doesn't sound very secure. I could be wrong but when I see Java I get the suspicion that user code and privileged server code are running in the same process. Of course they could have a properly sandboxed java process and are just using Java because that is what they are familiar with.

That perspective is somewhat dated to be blunt. A modern Java deployment would be identical security wise to node, with one app per Java process running with the minimum of privileges.

I think you are being very polite here. Fearing the JRE/JVM in this particular way falls somewhere between superstitious and ignorant.

It is unsafe to mix trusted and untrusted code in the same process. This is why Chrome runs the renderer in a separate process. My concern is that using Java to execute JS increases the probability they are doing this bad mixing. They could be doing it safely but it increases my suspicion.

I have no worries, because I make sure to sacrifice chickens to my Tomcat apps each day. Although going into the cloud is making it trickier, chickens generally can't fly that high.

Reply on news.ycombinator.com