Why does QEMU use JIT compilation?

Question

The TCG "accelerator" is used by QEMU when requesting full virtualization of a guest with a different hardware architecture (or with -accel=tcg).

TCG is a JIT compiler which emulates the guest architecture set by translating instructions and immediately invoking them at runtime. Portability depends on the list of architectures that TCG supports.

Would it be possible, realistically speaking, to compile an operating system into some efficient IR (similar to Java bytecode) and implement a virtual machine for that bytecode completely in software?

Considering that operating systems usually have low-level, hardware specific code you'd need to either have a virtual machine that supports those (which is essentially what the TCG JIT does) or rewrite the operating system to work with one specific virtual machine. So theoretically possible, but I'm not sure I see the use-case — UnholySheep, Oct 31 '21 at 21:53
@UnholySheep but most device drivers are completely emulated in software with QEMU, most hardware specific code as you call it consists of CPU instructions, which can clearly be "executed" in a full software VM, like the JVM. — explogx, Oct 31 '21 at 22:06
Yes, you could probably write a compiler that would output Java bytecode instead of machine instructions and would also be capable of translating hardware specific code into something portable. But what exactly would that gain you that QEMU's TCG doesn't already provide? — UnholySheep, Oct 31 '21 at 22:09
@UnholySheep this would probably give better portability, e.g., the bytecode generated could be run on any versions and underlying hardware of QEMU if it used a virtual machine implementation, whereas with JIT compilation, you still have a one-to-one coupling between TCG and the underlying hardware for every new architecture you need support fort — explogx, Oct 31 '21 at 23:14

score 1 · Accepted Answer · answered Nov 02 '21 at 15:34

The short answer to "why does QEMU use JIT compilation" is "because it is faster than other ways to do it, like interpreting, but it can still handle any arbitrary guest binary". There has been some work done (not in QEMU itself, but by other projects or research work) on emulation by statically translating guest binaries into code for the host architecture, but this is tricky and you still have to be able to fall back to something like JIT to handle guest binaries that involve self-modifying code or which themselves are JITs (think of running a Java guest inside QEMU).

It is certainly possible to have an operating system which is compiled into an IR bytecode which then executes portably on a virtual machine on a variety of hosts. Historical examples of this include Taos (http://www.uruk.org/emu/Taos.html) and the UCSD p-System (https://en.wikipedia.org/wiki/UCSD_Pascal). Note that you would still here probably want to implement the bytecode-execution engine in such a VM using a JIT, because it's faster than interpreting the bytecode, and there might well be some host-CPU-specific bits of the VM implementation as a result.

However, that sort of portable-operating-system endeavour is an entirely separate idea from QEMU, whose purpose is to run under emulation existing pre-built binaries for a given guest CPU architecture.

Why does QEMU use JIT compilation?

1 Answers1