Dynamic recompilation


In computer science, dynamic recompilation is a feature of some emulators and virtual machines, where the system may recompile some part of a program during execution. By compiling during execution, the system can tailor the generated code to reflect the program's run-time environment, and potentially produce more efficient code by exploiting information that is not available to a traditional static compiler.

Uses

Most dynamic recompilers are used to convert machine code between architectures at runtime. This is a task often needed in the emulation of legacy gaming platforms. In other cases, a system may employ dynamic recompilation as part of an adaptive optimization strategy to execute a portable program representation such as Java or.NET Common Language Runtime bytecodes. Full-speed debuggers also utilize dynamic recompilation to reduce the space overhead incurred in most deoptimization techniques, and other features such as dynamic thread migration.

Tasks

The main tasks a dynamic recompiler has to perform are:
A dynamic recompiler may also perform some auxiliary tasks:
Suppose a program is being run in an emulator and needs to copy a null-terminated string. The program is compiled originally for a very simple processor. This processor can only copy a byte at a time, and must do so by first reading it from the source string into a register, then writing it from that register into the destination string. The original program might look something like this:

beginning:
mov A, ; Put location of first character of source string
; in register A
mov B, ; Put location of second character of destination string
; in register B
loop:
mov C, ; Copy byte at address in register A to register C
mov ,C ; Copy byte in register C to the address in register B
inc A ; Increment the address in register A to point to
; the next byte
inc B ; Increment the address in register B to point to
; the next byte
cmp C,#0 ; Compare the data we just copied to 0
jnz loop ; If it wasn't 0 then we have more to copy, so go back
; and copy the next byte
end: ; If we didn't loop then we must have finished,
; so carry on with something else.
The emulator might be running on a processor which is similar, but extremely good at copying strings, and the emulator knows it can take advantage of this.
It might recognize the string copy sequence of instructions and decide to rewrite them more efficiently just before execution, to speed up the emulation.
Say there is an instruction on our new processor called movs, specifically designed to copy strings efficiently. Our theoretical movs instruction copies 16 bytes at a time, without having to load them into register C in between,
but will stop if it copies a 0 byte and set the zero flag. It also knows that the addresses of the strings will be in registers A and B, so it increments A and B by 16 every time it executes, ready for the next copy.
Our new recompiled code might look something like this:
beginning:
mov A, ; Put location of first character of source string
; in register A
mov B, ; Put location of first character of destination string
; in register B
loop:
movs , ; Copy 16 bytes at address in register A to address
; in register B, then increment A and B by 16
jnz loop ; If the zero flag isn't set then we haven't reached
; the end of the string, so go back and copy some more.
end: ; If we didn't loop then we must have finished,
; so carry on with something else.
There is an immediate speed benefit simply because the processor doesn't have to load so many instructions to do the same task, but also because the movs instruction is likely to be optimized by the processor designer to be more efficient than the sequence used in the first example. For example, it may make better use of parallel execution in the processor to increment A and B while it is still copying bytes.

Applications

General purpose