It's a template jit with a strange implementation.
Instead of writing the bytes directly, it uses llvm to compile functions that refer to external symbols and then patches copies of those bytes at jit time. That does have the advantage of being loosely architecture agnostic.
Template jits can't register alloc across bytecodes so that usually messes up performance. That can be partially mitigated by picking the calling convention of the template/stencils carefully, in particular you don't want to flush everything to/from the stack on every jump for a register architecture.
It's not in the same league of engineering as luajit, but then not much is.
This article is about a technique "Copy-and-Patch" for just-in-time (JIT) compilation that is both fast to compile, produces reasonably efficient machine code, and is easier to maintain than writing assembly by hand.
The section "Copy-and-Patch: the Art of Repurposing Existing Tools" describes the heart of the method, which is to use an existing compiler to compile a chunk of c/c++ code corresponding to some bytecode instruction, then patch the resulting object file in order to tweak the result (e.g. to specify the instruction operands) in a similar fashion to symbol relocation happening during link.
Given a stream of bytecode instruction, the JIT compilation reduces to copying code objects (named "stencils") corresponding to bytecode instructions from a library of precompiled stencils then patching the stencils as needed, which is very fast compared to running a full-blown compiler like LLVM from the syntax tree.
Of course, the resulting code is slower than full-blown Ahead-of-Time (AOT) compilation, but the authors describe a few tricks to keep the execution speed within a reasonable margin of AOT. For instance, they leverage tail calls to replace function calls with jumps, compile sequences of frequently associated bytecode instructions together, and so on.
My advice would be to read Piumarta's "Optimizing direct threaded code by selective inlining" paper [1] first, and then read the references from the wikipedia article [2].
If the piumarta paper is still over your head, take a look at its references, but they will refer to Java, SmallTalk and Forth which might be a distraction.
