GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀 (by oracle)

Graal Alternatives

Similar projects and alternatives to Graal

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better Graal alternative or higher similarity.

Graal discussion

Log in or Post with

Graal reviews and mentions

Posts with mentions or reviews of Graal. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-06-23.
  • Cosmopolitan v3.5.0
    14 projects | | 23 Jun 2024
    Too bad it looks stuck since about a month ago (, needs some attention from @jart.
  • Migrating from Java 8 to Java 17: A Comprehensive Guide to New Features
    1 project | | 22 Jun 2024
    Really now? Now that's interesting. I thought GraalVM might be a good option in that space last I checked, but something literally called Hermetic Java has my interest piqued.
  • One year of solo dev, wrapping up the grant-funded work
    1 project | | 19 Jun 2024
    Had to look back at the deep bug you described and I am happy that someone looked into it[1] and got it fixed.

    Also happy that they so publicly acknowledged your work to narrow it down!


  • Writing memory safe JIT compilers
    1 project | | 7 Jun 2024
    > TruffleRuby even had the extremely big brain idea of running a Truffle interpreter for C for native extensions […]

    TruffleC was a research project and the first attempt of running C code on Truffle that I'm aware of. It directly interpreted C source code and while that works for small self-contained programs, you quickly run into a lot of problems as soon as you want to run larger real world programs. You need everything including the C library available as pure C code and you have to deal with the fact that a lot of C code uses some UB/IB. In addition, your C parser has to fully adhere to the C standard and once you want to support C++ too because a lot of code is written in C++, you have to re-start from scratch. I don't know if TruffleC was ever released as open source.

    The next / current attempt is Sulong which uses LLVM to compile C/C++/Rust/… to LLVM IR ("bitcode") and then directly interprets that bitcode. It's a lot better, because you don't have to write your own complete C/C++/… parser/compiler, but bitcode still has various limitations. Essentially as soon as the program uses handwritten assembler code somewhere, or if it does some low level things like setjmp/longjmp, things get hairy pretty quickly. Bitcode itself is also platform dependent (think of constants/macros/… that get expanded during compilation), you still need all code / libraries in bitcode, every language uses a just so slightly different set of IR nodes and requires a different runtime library so you have to explicitly support them, and even then you can't make it fully memory safe because typical programs will just break. In addition, the optimization level you choose when compiling the source program can result in very different bitcode with very different IR nodes, some of which were not supported for a long time (e.g., everything related to vectorization). Sulong can load libraries and expose them via the Truffle FFI, and it can be used for C extensions in GraalPython and TruffleRuby AFAIK. It's open source [1] and part of GraalVM, so you can play around with it.

    Another research project was then to directly interpret AMD64 machine code and emulate a Linux userspace environment, because that would solve all the problems with inline assembly and language compatibility. Although that works, it has an entirely different set of problems: Graal/Truffle is simply not made for this type of code and as a result the performance is significantly worse than Sulong. You also end up re-implementing the Linux syscall interface in your interpreter, you have to deal with all the low level memory features that are available on Linux like mmap/mprotect/... and they have to behave exactly as on a real Linux system, and you can't easily export subroutines via Truffle FFI in a way that they also work with foreign language objects. It does work with various guest languages like C/C++/Rust/Go/… without modifying the interpreter, as long as the program is available as native Linux/AMD64 executable and doesn't use any of the unimplemented features. This project is also available as open source [2], but its focus somewhat shifted to using the interpreter for execution trace based program analysis.

    Things that aren't supported by any of these projects AFAIK are full support for multithreading and multiprocessing, full support for IPC, and so on. Sulong partially solves it by calling into the native C library loaded in the VM for subroutines that aren't available as bitcode and aborting on certain unsupported calls like fork/clone, but then you obviously lose the advantage of having everything in the interpreter.

    The conclusion is, whatever you try to interpret C/C++/… code, get ready for a world of pain and incompatibilities if you intend to run real world programs.



  • Garbage Collectors Are Scary
    3 projects | | 12 May 2024
    They are indeed scary, but one thing that can make them less so is writing them in a high level language. A nice code base to study if you're new to GCs is the GenScavange module of SubstrateVM, a JVM written entirely in Java. Start here:

    It gets compiled to native code for use. It's actually a bit of a dialect of Java because of course, you need low level memory and stack access. So you can see at parts there is use of special APIs that get compiled to things like stack allocations, so it can avoid allocating on the heap whilst working with it. Even so the "business logic" of a GC can be easily seen here, especially if you don't know C++.

  • Java 23: The New Features Are Officially Announced
    5 projects | | 17 Apr 2024
    Contrary to what vocal Kotlin advocates might believe, Kotlin only matters on Android, and that is thanks to Google pushing it no matter what.

    And even so, they had to conceed Android and Kotlin on their own, without the Java ecosystem aren't really much useful, thus ART is now updatable via Play Store, and currently supports OpenJDK 17 LTS on Android 12 and later devices.

    As for your question regarding numbers, mostly Java 74.6%, C++ 13.7%, on the OpenJDK, other JVM implementations differ, e.g. GraalVM is mostly Java 91.8%, C 3.6%.

    Two examples from many others,

  • FLaNK Stack 05 Feb 2024
    49 projects | | 5 Feb 2024
  • Apple releases Pkl – onfiguration as code language
    14 projects | | 3 Feb 2024
    Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futurama Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources!

    Disclaimer: graalvm dev here.

  • Live Objects All the Way Down: Removing the Barriers Between Apps and VMs
    1 project | | 8 Jan 2024
    That's pretty interesting. It's not as aggressive as Bee sounds, but the Espresso JVM is somewhat similar in concept. It's a full blown JVM written in Java with all the mod cons, which can either be compiled ahead of time down to memory-efficient native code giving something similar to a JVM written in C++, or run itself as a Java application on top of another JVM. In the latter mode it obviously doesn't achieve top-tier performance, but the advantage is you can easily hack on it using all the regular Java tools, including hotswapping using the debugger.

    When run like this, the bytecode interpreter, runtime system and JIT compiler are all regular Java that can be debugged, edited, explored in the IDE, recompiled quickly and so on. Only the GC is provided by the host system. If you compile it to native code, the GC is also written in Java (with some special conventions to allow for convenient direct memory access).

    What's most interesting is that Espresso isn't a direct translation of what a classical C++ VM would look like. It's built on the Truffle framework, so the code is extremely high level compared to traditional VM code. Details like how exactly transitions between the interpreter/compiled code happen, how you communicate pointer maps to the GC and so on are all abstracted away. You don't even have to invoke the JIT compiler manually, that's done for you too. The only code Espresso really needs is that which defines the semantics of the Java bytecode language and associated tools like the JDWP debugger protocol.

    This design makes it easy to experiment with new VM features that would be too difficult or expensive to implement otherwise. For example it implements full hotswap capability that lets you arbitrarily redefine code and data on the fly. Espresso can also fully self-host recursively without limit, meaning you can achieve something like what's described in the paper by running Espresso on top of Espresso.

  • Crash report and loading time
    1 project | /r/fabricmc | 15 Nov 2023
    I'm also using GraalVM if that's of any help.
  • A note from our sponsor - SaaSHub | 18 Jul 2024
    SaaSHub helps you find the best software and product alternatives Learn more →


Basic Graal repo stats
6 days ago

Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

Did you konow that Java is
the 8th most popular programming language
based on number of metions?