5 ms·

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

by mgdev 3y ago

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 3y ago
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.
- shellac 3y ago
  > [...] 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.
  - weinzierl 3y ago
    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.
  - switchbak 3y ago
    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 3y ago
      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/ https://www.graalvm.org/latest/graalvm-as-a-platform/
- aseipp 3y ago
  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.
- mike_hearn 3y ago
  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 https://github.com/oracle/graalvm-reachability-metadata
  - logicchains 3y ago
    >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 3y ago
      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
      - mike_hearn 3y ago
        I'm not sure any of those are actually quite right. Valhalla supports flattening, that's the whole point of it. To get that you need to have a type declared as a value type, and then put it into a non-null variable, field or parameter. At least that's how the current prototype works. If you do that then the compiler will fully inline the allocation into arrays, containing objects/structs, or the stack. Valhalla started with monomorphization prototypes, although that went silent years ago. I don't know if it'll be delivered in the first version. But, it's an intended goal of the project to deliver. As for the final point, could you evidence that? It's very hard to do direct comparisons here because they're usually compiling very different languages and Graal hasn't been optimized for C++. For example, Graal can compile many languages LLVM just doesn't even try to. Also, you'd really need to compare against the Oracle GraalVM (née GraalVM Enterprise) to see the best of what it can do. I'm curious what comparison you're thinking of when you say that, as Graal is an extremely advanced compiler by any measure.
- pjmlp 3y ago
  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.
- paulddraper 3y ago
  > 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.
- jabradoodle 3y ago
  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 3y ago
    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 3y ago
      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.
      - grashalm 3y ago
        With the new GFTC license, we hope G1 is much more accessible now.
    - kaba0 3y ago
      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.
- atgreen 3y ago
  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.
- emptysongglass 3y ago
  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?
- pdntspa 3y ago
  It would be really nice if it didn't shit the bed over Swing apps. Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.
doctorpangloss 3y ago
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.
mlinksva 3y ago
https://www.graalvm.org/latest/security-guide/polyglot-sandbox/ 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?
- gavinray 3y ago
  Many of the configuration settings set by a sandboxing policy are available when creating Polyglot contexts with the Community Edition.
  - MrPowerGamerBR 3y ago
    Are you sure? I created a JavaScript Polyglot context in Java with GraalJS CE 21 and... > Exception in thread "main" Polyglot sandbox limits can only be used with runtimes that support enterprise extensions. The runtime 'GraalVM CE' does not support sandbox extensions.
- grashalm 3y ago
  The Polyglot sandbox is licensed under GFTC: https://www.oracle.com/downloads/licenses/graal-free-license.html 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 3y ago
    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.
foobarbazetc 3y ago
We use Graal to sandbox a scripting language based on EcmaScript 6 for our app. It’s great.
- neeleshs 3y ago
  Can you say more on this? We're trying to do something similar and curious to know more

by mgdev 3y ago

weinzierl 3y ago

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.

shellac 3y ago
> [...] 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.
- weinzierl 3y ago
  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.
- switchbak 3y ago
  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 3y ago
    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/ https://www.graalvm.org/latest/graalvm-as-a-platform/
aseipp 3y ago
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.
mike_hearn 3y ago
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 https://github.com/oracle/graalvm-reachability-metadata
- logicchains 3y ago
  >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 3y ago
    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
    - mike_hearn 3y ago
      I'm not sure any of those are actually quite right. Valhalla supports flattening, that's the whole point of it. To get that you need to have a type declared as a value type, and then put it into a non-null variable, field or parameter. At least that's how the current prototype works. If you do that then the compiler will fully inline the allocation into arrays, containing objects/structs, or the stack. Valhalla started with monomorphization prototypes, although that went silent years ago. I don't know if it'll be delivered in the first version. But, it's an intended goal of the project to deliver. As for the final point, could you evidence that? It's very hard to do direct comparisons here because they're usually compiling very different languages and Graal hasn't been optimized for C++. For example, Graal can compile many languages LLVM just doesn't even try to. Also, you'd really need to compare against the Oracle GraalVM (née GraalVM Enterprise) to see the best of what it can do. I'm curious what comparison you're thinking of when you say that, as Graal is an extremely advanced compiler by any measure.
pjmlp 3y ago
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.
paulddraper 3y ago
> 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.
jabradoodle 3y ago
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 3y ago
  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 3y ago
    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.
    - grashalm 3y ago
      With the new GFTC license, we hope G1 is much more accessible now.
  - kaba0 3y ago
    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.
atgreen 3y ago
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.
emptysongglass 3y ago
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?
pdntspa 3y ago
It would be really nice if it didn't shit the bed over Swing apps. Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.

doctorpangloss 3y ago

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.

mlinksva 3y ago

https://www.graalvm.org/latest/security-guide/polyglot-sandbox/ 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?

gavinray 3y ago
Many of the configuration settings set by a sandboxing policy are available when creating Polyglot contexts with the Community Edition.
- MrPowerGamerBR 3y ago
  Are you sure? I created a JavaScript Polyglot context in Java with GraalJS CE 21 and... > Exception in thread "main" Polyglot sandbox limits can only be used with runtimes that support enterprise extensions. The runtime 'GraalVM CE' does not support sandbox extensions.
grashalm 3y ago
The Polyglot sandbox is licensed under GFTC: https://www.oracle.com/downloads/licenses/graal-free-license.html 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 3y ago
  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.

foobarbazetc 3y ago

We use Graal to sandbox a scripting language based on EcmaScript 6 for our app. It’s great.

neeleshs 3y ago
Can you say more on this? We're trying to do something similar and curious to know more