[HN Gopher] GraalVM for JDK 21
___________________________________________________________________
GraalVM for JDK 21
Author : fniephaus
Score : 169 points
Date : 2023-09-19 14:48 UTC (8 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| pregnenolone wrote:
| I use Graal Native to AOT compile my JavaFX applications. It
| works surprisingly well.
| Alifatisk wrote:
| I've slowly been keeping myself updated regarding GraalVM, I
| think Oracle is on to something here.
| mgdev wrote:
| GraalVM is a hugely under-appreciated piece of technology. A lot
| of my initial interest came from being able to blend different
| languages into a single runtime via the polyglot APIs, but the
| combination of performance, strong sandboxing support, and multi-
| language support has helped it emerge as a key primitive for
| anyone wishing to build extensible platforms without sacrificing
| speed, security, or developer ergonomics.
| weinzierl wrote:
| It's fascinating technology, but in my opinion too little, too
| late.
|
| Compiling with GraalVM is still a pain and will not work out-
| of-the-box without modifications for any non-trivial project.
| This is mostly, I believe, not GraalVM's fault, because it can
| only do so much within the confines of the existing ecosystem.
|
| If only AoT compilation to native code would have been taken
| seriously from the start, if only gcj would have gotten more
| attention, we could have ended up with an ecosystem that is
| somewhat amenable to what GraalVM tries to do.
|
| As much as I like GraalVM and wish it success, my prediction is
| that in a few years it will be in the same state gcj has been
| quite some years now.
| mike_hearn wrote:
| gcj had a lot of problems beyond needing configuration of
| reflection metadata. It used a full reimplementation of the
| standard library, and it was never adopted by the wider Java
| community being largely just Red Hat's strategy for creating
| a fully open source Java implementation rather than something
| offering specific benefits to Java developers. In particular
| people thought it'd lead to faster code, but GCC was never
| designed for Java and the results were actually a fair bit
| slower iirc.
|
| Native image is quite different. With this new release the
| compiled images can not only be faster than JIT compiled Java
| (wow) but also use way less memory and start instantly. At a
| stroke this is resolving one of the biggest complaints people
| have always had against JVM languages.
|
| And as a consequence you're seeing adoption by the wider
| community. All the modern Java web frameworks support it now,
| and there's a metadata repository where it's collected for
| projects that haven't accepted it upstream yet [1].
|
| [1] https://github.com/oracle/graalvm-reachability-metadata
| soulbadguy wrote:
| > With this new release the compiled images can not only be
| faster than JIT compiled Java (wow) but also use way less
| memory
|
| Source ?
| logicchains wrote:
| >With this new release the compiled images can not only be
| faster than JIT compiled Java (wow) but also use way less
| memory and start instantly
|
| Does this mean that once Project Valhalla lands, Java via
| Graal will be a viable competitor to C++ for tasks
| requiring extremely high performance?
| soulbadguy wrote:
| Possible, but i don't think it's very likely. Project
| Valhalla is a big umbrella term but couple of important
| points :
|
| - The new value type don't garanty flat memory
| representation, so might have some corner cases which are
| not properly optimized
|
| - The monomorphization or java vs C++ is still a big
| advantage for c++
|
| - The compiler optimization of LLVM/GCC are still quite a
| bit better (in term of generated code) vs jvm/graal
| jabradoodle wrote:
| Were talking enterprise java, it's a behamouth and changing
| it takes forever.
|
| I think in today's ecosystem of microservices and serverless
| etc, AOT will be taken pretty seriously.
| adra wrote:
| Everything has a cost though. The one thing we lose is the
| ability for hotspot to change its mind and recompile code
| based on usage patterns I've toyed with graalvm for some
| uses and ended up with lost performance. Also a key note is
| that it only supports a pretty naive serialgc right now
| which is a big limitation. Bellsoft has a parallelgc which
| probably plays a little better, but we're always going to
| need to play trade-offs until they can support the more
| robust GC impls
| hueho wrote:
| The serial GC is a limitation of the community (OSS)
| edition. The enterprise proprietary version has G1
| support.
|
| I hope Oracle will let it drip it down to the CE, but
| it's their project, their monetization strategy.
| kaba0 wrote:
| You can try to use Graal as a JIT compiler as well, in
| case of Scala for example that has a bit more indirection
| on average it can cause some speedups.
|
| Otherwise, it trades blows with hotspot.
| shellac wrote:
| > [...] my prediction is that in a few years it will be in
| the same state gcj has been quite some years now.
|
| You make it sound like GraalVM is just for ahead-of-time
| compiling like gcj, but there's more to it than native image.
| It's possible GraalVM will be openjdk's jit compiler, for
| example.
| switchbak wrote:
| This is one of my challenges with the branding of the
| project - it's not super clear to me what folks are talking
| about when they mention Graal related tech.
|
| That alone I think can muddy the waters and can even hurt
| adoption. I wish they had clear and meaningful names for
| the specific distinct pieces of tech (even if there is some
| shared underpinnings).
| uticus wrote:
| I agree, from an outside perspective it is bewildering.
| Especially when GraalVM itself becomes a platform for
| other languages, ie Truffle
| https://www.graalvm.org/latest/graalvm-as-a-platform/
| weinzierl wrote:
| Good point. It _is_ fascinating technology, but to get
| development resources in the long run it needs management
| /sponsor attention and for that it needs a practical use
| case today. That, I think is AoT compilation and I believe
| that, unfortunately, it doesn't cut it there.
| aseipp wrote:
| I think the reality is that faster startup, smaller
| deployments, and lower memory usage is considered much more
| valuable today than it was when GCJ was an actively
| maintained project. It simply did not offer things people
| needed at that time. But now, the tradeoffs are different,
| and so the effort of going back and modifying existing code
| to support AOT compilation has a greater overall payoff than
| it did in the past, which is why people are pursuing it. It's
| the same reason .NET is adding full AOT support - because
| people want it now, and they want it now more than they did
| before.
| paulddraper wrote:
| > my prediction is that in a few years it will be in the same
| state gcj has been quite some years now
|
| I'll take that bet.
|
| GraalVM has only gotten more and more popular.
|
| There are a lot of situations (large server applications)
| that don't benefit much from AOT.
|
| But others do. Android is (partially) AOT.
| pjmlp wrote:
| It was taken seriously, as commercial 3rd party offering,
| from which PTC and Aicas are the surviving vendors.
|
| Also Android uses a mix of AOT and JIT since version 5.
| emptysongglass wrote:
| As someone on the outside looking at GraalVM with curiosity,
| is it even possible to use something like Poetry to manage
| the Python part? Would you do that? Would I even need a venv
| anymore? Where would its edges be? What are the limits?
|
| How are we people practically putting this polyglot stuff
| into action?
| atgreen wrote:
| I worked on gcj (and GNU Classpath) for a number of years.
| gcj's origins are in the embedded systems space, where our
| customers valued the small memory footprint and portability
| across processor architectures that were unlikely to get
| performant JITs. As we eased out of the embedded space, it
| was clear that jumping on the OpenJDK train was the right
| choice for Free Software-minded gcj/Classpath devs, as Sun
| adopted the GPL and GNU Classpath exception license. gcj was
| unlikely to ever catch up, and many of us were motivated by
| the idea of a Free Software Java solution, which Sun just
| handed to us.
| doctorpangloss wrote:
| The NodeJS performance is really bad for many use cases, such
| as anything you do to build a web app. It has a long way to go
| in terms of becoming practical.
| foobarbazetc wrote:
| We use Graal to sandbox a scripting language based on
| EcmaScript 6 for our app.
|
| It's great.
| neeleshs wrote:
| Can you say more on this? We're trying to do something
| similar and curious to know more
| mlinksva wrote:
| https://www.graalvm.org/latest/security-guide/polyglot-sandb...
| looks very interesting though enterprise (not open source I
| assume?) only and maybe only for executing javascript? Or do I
| misunderstand, or is there other sandboxing support?
| grashalm wrote:
| The Polyglot sandbox is licensed under GFTC:
| https://www.oracle.com/downloads/licenses/graal-free-
| license...
|
| ISOLATED and UNTRUSTED require GFTC
|
| CONSTRAINED is also available under open-source licenses.
|
| Only for JavaScript right now. We are working hard on
| supporting all the other languages!
|
| Developer here. So, if you have more questions, let me know!
| mlinksva wrote:
| Thanks for explaining and for your work!
|
| Not sure I have questions, just generally interested in
| making it easier/lighter weight/built-in to constrain
| ambient authority (for example, to mitigate supply chain
| risks), thus have it be done more.
|
| The Polyglot sandfox feels very loosely analogous to Deno
| per process (and thus subprocess) permissions, though it
| looks like ISOLATED and UNTRUSTED can limit a bunch of
| things not possible with Deno.
| grashalm wrote:
| We do not do process isolation yet, although we have
| plans to implement that as well as a fallback strategy.
|
| The advantage of the native-image-isolate-based isolation
| is that it is much more lightweight. For example, calls
| from and to the host application are much faster. There
| is no copying or expensive synchronization necessary. The
| disadvantage is that we need to do our own protections
| against attacks, as the OS protections between processes
| don't apply to such isolates. By default, we deploy
| software/compiler-based protections but are also very
| close to supporting hardware like Intel MPK.
|
| If you have more questions, you can also drop by on
| Slack; we are a friendly bunch:
| https://www.graalvm.org/slack-invitation/
| gavinray wrote:
| Many of the configuration settings set by a sandboxing policy
| are available when creating Polyglot contexts with the
| Community Edition.
| Jumziey wrote:
| Lots of comments about issues with dependencies and Graal. I
| suggest looking into Quarkus. Have had great success with and
| mandrel (a patched version of Graal for Quarkus). Quarkus focuses
| on creating Web APIs so wont cover it all but if thats what you
| want to do its great and builds native images quite easily.
| refset wrote:
| The linked sibling post on "New Truffle and GraalVM Languages
| release" feels rather exciting too
| https://medium.com/graalvm/new-truffle-and-graalvm-languages...
|
| Specifically:
|
| > GraalVM language runtimes (for JavaScript, Python, Ruby, Java
| on Truffle, WebAssembly, and LLVM) can now be [...] installed as
| Maven/Gradle dependencies [...] which will work for GraalVM JDK
| and any other compatible JDK
|
| Polyglot experimentation just got a whole lot easier! Kudos to
| everyone involved in pushing the JVM ecosystem forwards.
| monlockandkey wrote:
| I am more interested in this proposal
|
| https://openjdk.org/jeps/8313278
|
| It is "Ahead of Time Compilation for the Java Virtual Machine".
| The proposal details of using AOT code at startup and then JIT
| taking over. So you get best of both worlds with fast application
| launch and then throughput once things are warmed up.
|
| Graal is cool, but it will not be as throughput performant
| compared to JIT. Only for fast startup, serverless or low memory
| environments.
| ezst wrote:
| The linked post shows the AoT compiler ahead of the JIT one, it
| seems like PGO really closes the gap :)
| kaba0 wrote:
| Not sure if you are aware of it, but Graal is also a JVMCI-
| comparible JIT compiler.
|
| Also, there was a proposal (not yet JEP though) on condensers
| and that model could also make great use of GraalVM.
| alberth wrote:
| What's the latest on Truffle/Ruby supporting Rails?
|
| Wouldn't this provide massive gains for the Rails ecosystem once
| delivered?
|
| (And with the GraalVM licenses changes to be more
| favorable/permission, I have to imagine there would be
| significant adoption)
| uticus wrote:
| GitHub page has some info:
| https://github.com/oracle/truffleruby#current-status
|
| My question is, how viable is TruffleRuby vs JRuby?
| jsight wrote:
| I just wish the compile times weren't so painfully slow. It makes
| it really difficult to work with.
| kaba0 wrote:
| You can generally develop with the JDK, and only compile from
| time to time.
| jcadam wrote:
| Seems like every time I try to use Graal - there's some
| dependency in my project that doesn't like it.
| tombert wrote:
| I've only done one project with GraalVM and I've been pretty
| happy with it in regards to faster startup time.
|
| I was doing stuff in Clojure. Clojure is a great language but it
| tends to have very slow startup times, even by JVM standards
| (it's not weird for a large Clojure program to take 5-6 seconds
| to start. Even a "hello world" can take upwards of a second or
| two). Graal mostly Just Worked with the standalone uberjar
| produced by Leiningen and created an executable that started in
| about 3 milliseconds. It was amazing.
|
| While the lack of proper reflection support was a little
| annoying, it actually wasn't as horrible with Clojure as you
| might think; most problems were fixed with basic type hinting,
| and all but one Clojure library I used (http-kit) worked
| flawlessly.
| lispisok wrote:
| What are the applications where slow startup time is such a big
| issue?
| amelius wrote:
| Commandline tools?
| Nihilartikel wrote:
| Serverless apps possibly.
| dig1 wrote:
| The recurring problem I've seen that would cause slow startup
| is cramming many (require) and (import) in the project core.clj
| file - for non-clojure devs here, this means including a lot of
| dependencies in the file called on the startup.
|
| By reordering things to be loaded smartly or lazily, startup
| speed can be improved a lot.
|
| Another reason for a slow startup is that Clojure must load its
| own runtime every time. The current compiler is not a tree
| shaker, nor can it rewrite complex expressions in compile-time,
| although many clojure.core functions were rewritten over time
| to accommodate JVM optimizers. However, Graal is here precisely
| to do at the bytecode level, as long as you take care of all
| type hint warnings and avoid things Graal can't see during
| compilation (e.g. deferring evaluation of some expressions for
| runtime).
| gzalo wrote:
| We tried to use it to improve AWS lambda startup times but
| desisted as it was a pain to use it with an existing app. It
| required too many tweaks as there are waay too many things that
| rely on reflection :(
|
| Things that broke include: JSON (de)serialization using Jackson,
| validations using hibernate, validator, AWS SDK, and even simpler
| libs like picocli...
|
| It could be quite useful for a set of simpler apps though
| jiehong wrote:
| Picocli allows using a compiler annotation processor to
| generate classes at compile time instead [0].
|
| [0]: https://github.com/remkop/picocli/blob/main/picocli-
| codegen/...
| AndyPa32 wrote:
| Yes, Jackson really was a bummer. To this day I can't
| understand how a project like Springboot advertises Graalvm
| readiness when Jackson is not supported without tweaks. What do
| the Springboot devs think we are using Springboot for, Hello
| World blog posts?
| CrimsonRain wrote:
| What's wrong with it? Genuinely curious. I've using Graal
| with spring/Jackson for a long time and haven't noticed any
| issue.
| JacobiX wrote:
| From my understanding, Spring Boot takes care of providing
| the JSON metadata for many libraries, including Jackson. So
| in practice, it can be more straightforward to use it in a
| Spring Boot project.
| wizwit999 wrote:
| ye even less relevant for that usecase with snapstart.
| wink wrote:
| SnapStart for Java 17 was only released _very_ recently, so
| if you are a bit early in the cycle it doesn 't help. Don't
| even want to guess when it will be available for Java 21.
| eddythompson80 wrote:
| this was our experience as well. Both with GraalVM/Quarkus and
| .NET CrossGen/Native/CoreRT. It's almost a different platform
| that's far less supported and less stable. Even if you put in
| the work to make things work, they'll eventually break. Quarkus
| tries to give a full experience like Kotlin Native, but both
| are also not really there.
|
| It's really unfortunate how Java and C# are perceived as _slow_
| because of their painful startup time.
| Kingpin007 wrote:
| [flagged]
| sgammon wrote:
| it's time to do a barrel roll
| sgammon wrote:
| Congrats to the GraalVM team on all their hard work
| amelius wrote:
| Warning: Graal is owned by a law-firm called Oracle (that happens
| to employ some programmers too).
| mwcampbell wrote:
| Who is actually at risk of falling victim to Oracle's infamous
| licensing shakedowns, though? And how bad are they actually?
| [deleted]
| uticus wrote:
| From 5 years ago, but still fascinating: Ten Things You Can Do
| With GraalVM by Chris Seaton
|
| https://gist.github.com/chrisseaton/535e0e80ea19803d5529c623...
___________________________________________________________________
(page generated 2023-09-19 23:00 UTC)