[HN Gopher] GraalVM 22.1: Developer experience improvements, App...
___________________________________________________________________
GraalVM 22.1: Developer experience improvements, Apple Silicon
builds, and more
Author : fniephaus
Score : 132 points
Date : 2022-04-26 14:36 UTC (8 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| tiffanyh wrote:
| I've always wondered if the perf silver bullet for Rails would be
| Graal/Tuffle.
| adamgordonbell wrote:
| It doesn't seem like it. I think the newly added Ruby jit that
| you can optionally turn on is faster than Graal with a lot less
| startup time.
| chrisseaton wrote:
| > the newly added Ruby jit that you can optionally turn on is
| faster than Graal
|
| No TruffleRuby is still very much faster than any other Ruby
| JIT. YJIT does startup faster yes that's the goal.
|
| https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-
| yj...
| tiffanyh wrote:
| Hi Chris
|
| Do you see by the end of 2022, Rails being able to run on
| TruffleRuby?
| chrisseaton wrote:
| I think you _can_ run Rails on TruffleRuby, but probably
| not _your Rails application_. We 're working hard on it,
| both at Oracle and Shopify.
| tiffanyh wrote:
| Just FYI - I don't know if your response was intended to
| deflect on an eta but some might perceive it as that
| since you didn't indicate if 2022 would be the year.
| Which might imply to some that it's not.
| chrisseaton wrote:
| > I don't know if your response was intended to deflect
| on an eta
|
| Lol it was. I don't know - it's research it's open ended.
| fire wrote:
| good god these performance differences are legitimately
| terrifying
| adamgordonbell wrote:
| I opened a ticket some time ago about performance with
| Jekyll and liquid templates. At least in that case, yjit
| was way faster. I'm happy to retest though. Anything that
| would make my jekyll builds faster would help.
|
| Thanks for your great work!
|
| https://github.com/oracle/truffleruby/issues/2363
| chrisseaton wrote:
| Yeah there's examples of bugs and bad optimisations that
| are easy to come across of course.
| kaba0 wrote:
| I believe so. Especially with the possibility of optimizing
| across language barriers could mean that a C function can be
| inlined, resulting in possibly faster execution than native
| FFI.
|
| The problem to my knowledge is that such a complex platform can
| even depend on some buggy side-effect down the line, so perfect
| interop is hard.
| eatonphil wrote:
| > Graal was included in HotSpot-based Java VM releases like
| OpenJDK from Java 9 through 15, but was removed in Java 16 for
| lack of use.
|
| From wikipedia [0].
|
| What's the deal with GraalVM today? I guess Oracle is still
| keeping it alive since this is a post by an Oracle team.
|
| Does it have a future or is it going to be abandoned or what is
| the plan?
|
| [0]
| https://en.wikipedia.org/wiki/GraalVM#:~:text=The%20GraalVM%....
| kaba0 wrote:
| As mentioned by sibling poster, it really is not a setback,
| they just have different release schedules.
|
| Graal is doing pretty well, it is heavily used by Twitter for
| example. And the polyglot part is simply completely novel and
| very exciting - it can basically optimize across language
| boundaries with it. A python call to a C function might get
| inlined and be much faster than native FFI. Enterprise edition
| also has managed mode for LLVM bitcode, making for example
| existing C code use managed heap for allocations. TruffleRuby,
| Graal's ruby implementation is the fastest ruby runtime by a
| huge margin and the JS runtime developed by comparatively few
| people (compared to V8 and the like) can achieve similar
| performance to it.
| KMag wrote:
| 20 years ago, I was a lurker on the JikesRVM (IBM's research
| project building a JVM in Java) mailing list. JikesRVM is still
| around, but not terribly active last I checked. Oracle is quite
| late to the game, and I'm just generally sad that Oracle ended
| up owning Java instead of IBM (or perhaps Google, but my trust
| in Google seems to be monotonically decreasing).
|
| Last I checked, Oracle's AoT compiler threw away any metadata
| necessary for HotSpot to be able to trace its way trough the
| native code, so if your AoT-compiled code was part of a hot
| loop, HotSpot wouldn't be able to perform any inlining or other
| runtime optimizations of your code. It seems like fixing this
| would be a first step to having a high performance JVM written
| in Java with start-up/warm-up time comparable to a JVM written
| in C++.
|
| While we're at it, Erlang/Elixir/BEAM's NIFs seem the right way
| to implement native code extensions to your VM. You write
| implementations in your language that get replaced with native
| versions if the native library is successfully loaded. Maybe
| your non-native implementation is just a stub that throws if
| it's called. With a few lines at the top of your module, you
| can attempt to load one or more native libraries and
| handle/ignore any errors. This makes it much easier to
| gracefully degrade if a particular native library isn't
| available on the local machine (or even available for the
| platform). It's a real pain to fall back to a Java
| implementation if the JNI implementation isn't available for
| any reason.
| pjmlp wrote:
| It was Oracle that turned the MaximeVM research project into
| GraalVM, bringing it outside of the research lab.
|
| IBM would have killed it instead, J9 already provides AOT and
| JIT caches, almost a decade older before such capabilities
| landed on OpenJDK.
| lvh wrote:
| Point of order since native-image is a party piece for
| Graal: AOT is more in the sense of JIT (but, well, ahead of
| time) than a self-standing binary a la native-image, right?
| pjmlp wrote:
| GraalVM uses its JIT infrastructure for AOT compilation,
| but it is still AOT, nee SubstrateVM.
|
| Or do you mean J9?
|
| It grew out of the Metromone project for embedded
| deployment.
|
| https://researcher.watson.ibm.com/researcher/view_group.p
| hp?...
| chrisseaton wrote:
| I'm not sure including it in OpenJDK was ever a major goal, so
| removing it wasn't the setback I think you're mistaking it for.
| eatonphil wrote:
| Yeah could be. I was just thinking that organizationally
| being part of OpenJDK sounds like a big thing and pulling
| back from that sounds like a reversal of a big thing. I'm
| sure the team wasn't extremely happy about it.
| chrisseaton wrote:
| I don't recall anyone even having an opinion about it to be
| honest - we didn't put it in in the first place.
| eatonphil wrote:
| Ok then! :)
| [deleted]
| papercrane wrote:
| GraalVM has always been built and maintained outside of the
| OpenJDK. Staring with Java 9 Oracle started including it with
| OpenJDK to provide AOT compilation, but as the article says, it
| wasn't widely adopted by OpenJDK users.
|
| Most people who wanted AOT would use GraalVM directly, so for
| most people nothings changed. Those that did use the OpenJDK
| AOT will have to migrate to using GraalVM's tooling post Java
| 15.
| kaba0 wrote:
| To my knowledge, another reason for the exclusion of Graal
| from OpenJDK was the different release cycle of development.
| The_rationalist wrote:
| mark_l_watson wrote:
| My world revolves around Common Lisp (with Python for deep
| learning), but Clojure is also an important language to me
| because of both professional use and I wrote a Clojure AI book.
|
| What is the Graalvm + Clojure situation? A quick web search shows
| some use cases. I find the idea of using high programmer-
| efficient Lisp languages and then building small and fast native
| applications to be compelling. That said, LispWorks, SBCL, and
| Allegro CL are all good for building standalone apps.
| zorr wrote:
| If you have a clojure project that builds to a single .jar file
| at hand, you can give it a quick shot using the native-image
| command from the GraalVM. If you're not using reflection-heavy
| libraries chances are it will just work and spit out a binary.
| mark_l_watson wrote:
| Wonderful, thanks.
| kaba0 wrote:
| It can compile Clojure to native executables but do note that
| Graal's AOT part doesn't promise better performance, just
| faster startup time and reduced memory usage. Using JIT
| compilers for long running processes (either the usual
| OpenJDK's hotspot or Graal's JIT compiler) will very likely
| beat the AOT compiled version for long running processes.
| pjmlp wrote:
| GraalVM AOT also accepts PGO.
| eklavya wrote:
| Can you please share your experience with PGO? I would be
| interested in some rough performance ballpark numbers for
| JVM languages.
| pjmlp wrote:
| I am just following its development, here is an article
| about it,
|
| https://medium.com/graalvm/improving-performance-of-
| graalvm-...
| Borkdude wrote:
| Examples of Clojure projects that compile to native:
|
| - babashka (https://github.com/babashka/babashka)
|
| - clj-kondo (https://github.com/clj-kondo/clj-kondo)
|
| - jet (https://github.com/borkdude/jet)
|
| SCI (https://github.com/babashka/sci) is a Clojure interpreter
| that allows you to evaluate Clojure code even inside of the
| final native binary and is used in all of the above projects.
|
| Feel free to bug me with questions in the graalvm channel on
| Clojurians Slack.
| christophilus wrote:
| I want to slap a bunch of side projects on a small VPS. With
| Go, this is no problem. Scp the binary (which includes an
| embedded SQLite), configure it to run as a systemd service,
| add it to my reverse proxy rules.
|
| I'd love to use Clojure for this, but it doesn't seem well
| suited to running in a small, shared environment. Or is it
| now that there's AOT?
| nathell wrote:
| I'm running a side project in Clojure (a guess-the-number-
| of-covid-cases lottery, https://koronalotek.pl) on a small
| VPS (Scaleway DEV1-S), and it is no problem either. It runs
| happily in the 2 GB RAM that the server has; I just
| installed the JVM, configured a nginx reverse proxy, and am
| using the standard cli-tools in a screen session to run it.
| melony wrote:
| Depends on how much value you place on performance. For
| long running processes like web servers, the JVM still
| reigns supreme.
| stingraycharles wrote:
| You should be fine, but it depends on your definition of
| "small VPS". Generally, assume that each process will need
| about 512MB of memory.
|
| You'll definitely want to restrict the JVM by memory,
| either by explicit flags (-Xmx ) or by running them in a
| cgroup or container.
| lvh wrote:
| Pretty similar with Clojure, though because it's not the
| default mode of operation, more stuff will break. Still, we
| do this all the time and it's mostly fine.
|
| That said, seems like you should be able to do something
| pretty similar fairly easily with jars and the JVM (you may
| not want to run lots of JVMs in the method you're
| describing, since if you're calling these processes in a
| one-shot, CGI-style fashion, the JVMs startup time and
| memory requirements is going to be annoying.)
|
| GP also linked babashka which may be closer to your
| interests, as its an interpreter for small scripts like
| these, but also comes with a mechanism (pods) for loading
| dependencies (like SQLite).
| mark_l_watson wrote:
| Thanks for the info!
|
| BTW, I enjoyed your ClojureScript+Node.js talk a few weeks
| ago.
| tombert wrote:
| I haven't touched GraalVM in a couple years, but the big-ish
| project that I did with it in Clojure was mostly painless,
| except for the fact that I had to use type-hinting a lot more
| frequently, due to the reduced reflection capabilities of
| GraalVM.
|
| Other than that, it was actually very pleasant.
| didibus wrote:
| Anyone uses one of the Truffle languages in production? Like any
| Ruby or Python users are deploying on Graal's TrufflePython or
| TruffleRuby?
| The_rationalist wrote:
| yes shopify runs on truffleruby. It is the fastest ruby VM by
| far and can seamlessly call state of the art Java libraries.
| GraalVM is the VM to rule them all and unify currently
| incompatible billions of dollars libraries ecosystems. Despite
| being the computer science breakthrough of the decade, people
| are not getting it yet.
| smasher164 wrote:
| I think Project Loom support will open up green thread support
| for more Truffle-based languages. I could see Go, Haskell,
| Erlang, Scheme, and Concurrent ML -style languages taking
| advantage of that infrastructure.
|
| I'm also hoping for official support for static linking. Right
| now, it's an undocumented feature done through the Feature API.
| rishav_sharan wrote:
| I tried Graal/Truffle last year, to make a toy language of my
| own. Unfortunately the state of documentation and tutorials was
| simply not good enough and I had to give up on it. I think for
| someone who is a Java/Graal enthusiast, Truffle documentation may
| be enough, but for someone like me who knows just the basics of
| Java and its ecosystem, the Truffle language implementation docs
| seemed woefully inadequate.
|
| Its a shame though, for what I did understand of Truffle seemed
| very interesting. I do plan on trying truffle yet again in a few
| years, when hopefully the community size and the state of the
| documentation have improved.
| fniephaus wrote:
| Do you have any feedback on how we could improve the docs? If
| so, please let us know.
|
| I believe the easiest way to start a new Truffle language
| implementation is to fork SimpleLanguage [1] and turn it into
| your language. Did you try to do that?
|
| [1] https://github.com/graalvm/simplelanguage
| grashalm wrote:
| I am sorry to hear you did not succeed in building your own
| language. I have to admit it is quite a steep learning curve.
| If you decide to retry do not hesitate to hit us up with
| questions on the community slack. We are a helpful bunch.
|
| Also I will drop my truffle seminar shamelessly here for you to
| watch: https://youtu.be/pksRrON5XfU
| zorr wrote:
| GraalVM is interesting technology. I've been playing a little bit
| with native-image in a Kotlin project and it allows me to build
| native binaries from my Kotlin code. With support for a lot of
| the existing java/kotlin library ecosystem.
|
| The binaries are a bit large (10MB for a Kotlin hello world) but
| they are fast. I'll be using this for some personal cli tools
| since Kotlin+Maven is my personal 10x platform.
|
| Besides cli projects I've also done some experimentation with GUI
| and database stuff. Using the Gluon plugin GraalVM is able to
| compile a native binary for a JavaFX app that talks to a Sqlite
| database.
|
| When using a library that relies on reflection there might be
| some graalvm config to fiddle with but mostly it just works, and
| some of the libraries are already "native-image ready" with the
| necessary config inside the published package.
| dangets wrote:
| Do you have a link to any example repos by chance? The need has
| slowly been growing for some cli tools I want to write, but I
| haven't taken the plunge yet. I'm the most curious about
| peeking at your maven setup.
| zorr wrote:
| I don't have anything public right now but the setup is
| pretty simple (although I use Gradle with the Kotlin DSL
| instead of Maven). It's your standard kotlin or java setup
| that can build a jar with dependencies included, and 1 extra
| build step to invoke `native-image` from the Graal SDK.
|
| https://github.com/pvorb/graalvm-kotlin-native-image-sample
| tealpod wrote:
| How smooth is JavaFX compilation to native? Any bugs/issues
| running the native version of JavaFX UI application?
|
| Thanks
| zorr wrote:
| native-image takes a minute to compile the binary from the
| jar but after that it's pretty smooth. I noticed my css
| styles where a bit different here and there but that could be
| due to differences in the default stylesheet used in my jvm
| build (OpenJDK with OpenJFX) vs the native-image build (using
| Gluon and maybe a customized JavaFX version)
| 0x500x79 wrote:
| Have you tried taking a look at UPX for the binary size? I
| found that it significantly decreased the size of the binary to
| the point where the problem was more the size of my
| dependencies (large JARs that could not be optimized away) and
| could get the binary to a completely manageable place. They
| aren't C small, but they were definitely better than
| traditional Java apps by an order of magnitude.
| eatonphil wrote:
| UPX doesn't play nice with antivirus software if it's
| important for you to run on Windows (at least).
|
| https://github.com/upx/upx/issues/337
| zorr wrote:
| I had not heard of UPX until just now and just did a quick
| test. With `-7` level it brings the 10MB binary down to 3.6MB
| but execution time was roughly x10.
| 0x500x79 wrote:
| I haven't touched this in a long-while, but I believe
| startup will be impacted but post startup the impact should
| be smaller once the binary has been loaded. It depends on
| how your executable is used of course, but a hello world
| application will show the worst performance degredation
| since the code is loaded then executed once.
| ComradePhil wrote:
| UPX used to be great when reading from disk took way too
| long... and having small binaries to read from disk and
| unpacking in memory was faster... but now in the age of
| SSDs, I don't know how much sense it makes to compress
| binaries.
|
| Back in the day, I used to use UPX on most apps, which
| would greatly improve launch times.
| coldtea wrote:
| Execution time should hardly be affected in any measurable
| way, except for trivial scripts.
___________________________________________________________________
(page generated 2022-04-26 23:01 UTC)