MoarVM: the JIT compiling runtime behind Rakudo

MoarVM exists to run the 6model object system natively

MoarVM expands to Metamodel On A Runtime Virtual Machine, and the name points at the design: it is a runtime built for the 6model object system rather than a general purpose bytecode VM with object support bolted on. The primary targets are NQP and Rakudo, but the documentation is careful about the wider case, stating that it should be able to serve as a backend for any compilers built using the NQP compiler toolchain.

That positioning is what makes it interesting to people who never write Raku. NQP is a bootstrap language, the low level syntax that Raku itself is compiled through, so anything that can target NQP inherits a path to a native runtime with a JIT compiler behind it. The repository is written in C, and the topic tags confirm the stack: jit, libuv, raku, rakudo, vm.

The project is not a fork or a wrapper of an existing VM. The source tree has src/, lib/, build/, tools/, ports/, docs/ and a 3rdparty/ directory, plus a Configure.pl driver at the root, which is the shape of a self contained runtime rather than a binding.

The 6model object system and NQP as the compile target

Two things in the architecture explain most of MoarVM's design decisions. The first is meta-object programming, which the feature list names first and attributes to the 6model design. The second is that NQP is not merely a language that runs on MoarVM, it is the compilation pipeline: the NQP compiler toolchain can target the MoarVM backend and, from there, anything written in Raku.

The build chain therefore has three links, and each link has its own configure step. MoarVM is built and installed first. Then NQP is configured against the installed VM so that it produces an nqp-m, the NQP compiler that runs on MoarVM. Finally Rakudo is configured with a prefix that contains that nqp-m, and the configuration detects the MoarVM backend automatically.

A detail worth noting for anyone automating this: the MoarVM repository is not integrated into the NQP source repository, unlike the JVM or JS backends. Instead it is pulled in by the configure script when you pass the --gen-moar flag, which lets that script clone, build and install a copy of MoarVM on its own.

Building the VM takes a configure step and a make

Getting the source is either a download from the MoarVM site or a clone from GitHub:

git clone https://github.com/MoarVM/MoarVM.git

The build then reduces to two commands from the repository root:

perl Configure.pl
make install

On Windows the equivalent targets are nmake or gmake. The supported combinations stated in the documentation are MSVC and gcc on Windows, and gcc and clang on Linux and MacOS X, with the note that the matrix is being expanded over time.

Configure options are discoverable in the usual Perl script way, and the documentation points you at `perl Configure.pl --help` for the configure time options and descriptions of the make time options and targets. That is worth doing before a first build, because the prefix option determines where the moar executable and the library files end up.

One trap catches nearly everyone: the automatically generated release tarballs and zip files do not contain the third party libraries needed to build successfully. If you start from a release archive rather than a clone, you will hit link errors that look like a broken toolchain.

Building NQP and Rakudo against an installed MoarVM

Once the VM is installed, NQP is configured with an explicit backend and the prefix where MoarVM lives:

perl Configure.pl --backend=moar --prefix=where_your_moarvm_install_lives

The prefix is not a detail you can wave through. It becomes the location of the /bin, /lib and other directories where the moar executable and related files are installed, so the documentation notes you have to use /usr if you want moar copied into /usr/bin.

The shortcut is the --gen-moar flag, which makes the same NQP Configure.pl script clone, build and install a copy of MoarVM by itself. That removes the manual ordering problem for newcomers, at the cost of a longer build.

For Rakudo the same logic applies one level up. Pointing Rakudo's Configure.pl at a prefix that already contains an nqp-m makes it detect and configure the MoarVM backend automatically. If you need both backends in one build, the documentation gives the explicit form --backend=moar,jvm, which forces the MoarVM and JVM backends to be built, and the --gen-moar option works there too, including the creation of an nqp-m.

Where the performance work actually sits

The feature list is long, but a few entries describe where the engineering effort goes. Bytecode specialisation by type is listed first among the optimisations, followed by resolution of method calls and multiple dispatch, dead code elimination, inlining, on stack replacement, scalar replacement and partial escape analysis. On top of that sits JIT compilation.

Memory management is described as precise, generational and parallel. The word precise matters in a Raku context, because a garbage collector that cannot move objects constrains the optimisations above. The feature list also names instrumentation based profiling of call frames and allocations, and heap snapshotting, which are the tools you need when the profiling data points at something.

Other runtime features include first class code objects, lexical variables and closures, exceptions, continuations, bounded serialization, runtime loading of code, big integers, native calling and native pointer manipulation, and a range of IO and process support covering asynchronous sockets, signals, timers and processes. Concurrency primitives listed are threads, mutexes, condition variables, semaphores and blocking queues.

Debugging gets attention too. The list mentions remote debugging with single stepping and variable and object introspection, which is a differentiator for a native VM, since it lets you attach to a running process without recompiling.

The macOS linker failure and mixed toolchains

The troubleshooting section deals with a specific, common failure: a build that dies with an error like `ld: symbol(s) not found for architecture x86_64`. The documented cause is an incompatible mix of build and bin utils, which happens because toolchains installed from third party repositories on macOS are not all compatible with each other.

The suggested recovery is short and blunt. Unlink the tools from homebrew with:

brew unlink binutils

Then destroy and re-clone MoarVM or rakudobrew, and build again from scratch. The repository is not reusable after a partial build in this state, which is worth knowing before you start work in a directory with local modifications.

If you deliberately want a GNU toolchain and hit an error pointing you at that file, the Configure script accepts a --toolchain=gnu flag and will configure and build with GNU tools instead. The documentation is explicit about the boundary: mixing Xcode and non-Xcode tools is unsupported and likely to cause trouble.

There is also a portability note for anyone writing C in the tree. Both gcc and clang define the macro __GNUC__, so the __clang__ macro has to be tested first to disambiguate the two compilers.

Status, licence and what a new contributor inherits

The status section is honest in a way most runtime READMEs are not. MoarVM is stated to be currently in development, and the specific claim is that it can run all of the NQP test suite and all of the Rakudo sanity tests, and passes more spectests than any other Rakudo backend. That is a comparative claim about the test suites rather than about application speed, and it is the kind of claim worth checking against your own workload.

The licence is where a procurement team needs to look. GitHub cannot classify it, so the repository is not under a standard OSI licence, and the project points readers at the LICENSE file in the root directory for the terms on the source code. The presence of Artistic2.txt alongside it suggests the licensing is a custom or hybrid arrangement rather than a single well known grant. Before embedding MoarVM in a product, read that file rather than assuming Apache-2.0 or MIT semantics.

Contributions arrive by pull request, and commit rights go to those whose work is good. The community channel is #moarvm on libera.chat. The recent release cadence is monthly, with 2026.07, 2026.08 and 2026.09 published in July, August and September 2026, and the last push was on 2026-10-13.

Editorial conclusion

MoarVM is the right choice for a team that wants to work on a native Raku runtime, extend NQP with a new compiler backend, or ship a statically targeted binary rather than depend on a JVM. It is the wrong choice for a team that needs a licence GitHub recognises out of the box, for one that wants a finished product rather than a runtime described as still in development, or for anyone expecting identical results across platforms since the supported platform matrix is explicitly still growing. Verify two things before starting: read the LICENSE file in the repository root, since GitHub cannot classify it, and check whether the third party libraries your build needs are present, because the release tarballs do not include them.

Frequently asked questions

Official sources

1. Issues
2. MoarVM/MoarVM on GitHub
3. Project website
4. README
5. Releases