Why does QEMU use JIT compilation?

Issue

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?

Solution

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.

Answered By - Peter Maydell