Memory Management of the target machine

Memory Management of the target machine

To allow binaries of the target machine to be executed on different platforms, the file may not need to be re-compiled. If the source file is encoded in big-Endian format and the given platform is little-Endian, the run-time on the target machine is responsible for the conversion.

To support portability, virtual machines must implement complete memory protection in software.

When the run-time of the target machine is called, it allocates memory from the local operating system to build a manual address space for a single application. The address space is precisely divided into three parts: Text, heap, and stack. The starting address of the text part is 0.
During compilation, the address of the test part is fixed, and the address size of the stack and heap parts is adjustable.

The Virtual Machine supports the command line option, allowing you to adjust the size of the stack and heap, which must be non-negative. Check whether the stack does not overflow to the heap part or the top of the prohibited address space.

Another thing to do to protect the local platform is to fix a certain amount of valid memory to the address space. Once the text, heap, and stack addresses are assigned, do this immediately. UNIX systems use the sbrk () function.

When the Virtual Machine initially loads an application to the memory, it performs a one-time check to determine the legitimacy of the program's binary encoding instructions. This one-time check is bytecode verification ). Check the virtual machine to check whether the command operations have the correct value. Check whether the address symbol is out of bounds. All command operation codes are valid.

To eliminate some risks caused by memory latency, it is best to load the run-time to the physical memory. Before the target machine creates an address space, the target machine makes a call to check the idle physical memory size. If the valid physical memory is insufficient, the virtual machine will not start.

The most complex is heap management. You can use the Display memory management mode. The reasons are as follows:
1) The implementation of most garbage collectors uses a multi-threaded environment, consuming a lot of CPU cycles. What if the target machine is not a multi-threaded environment?

2) virtual machines are designed to be portable, simple, and high-performance. Conservative garbage collectors like bdw collectors are not simple and cannot be transplanted immediately. Essentially, the Garbage Collector requires the run-time system to perform additional work to track allocated memory. These additional tasks introduce additional commands to reduce system performance.

Machine Design

The central processor can be implemented on registers or stack-based machines. Register-based processors, such as Intel's Pentium processor, and stack-based processors, such as Harris semiconductor's rtx32p, have two chip-based stacks to perform basic operations.

Stack-based processors are often more popular in the embedded field because they support smaller programs and more limited resources. For example, a stack-based Processor command such as iadd pops up two integers from the stack, sums them, and pushes the sum to the stack. The command is as follows:
Add $ R1, $ R2, $ r3
This command calculates the sum of $ R2 and $ R3 and puts it in $ R1.
The stack-based iadd command only requires one single byte. The register-based add Command requires at least four bytes.
Therefore, it is obvious that the stack-based machine requires shorter compilation time than the register-based machine.

Stack-based computers also execute function calls more efficiently. Because function parameters are stored in the stack. For register-based computers, the function parameters must be accessed and manually put into the stack. More work is required.

Stack-based computers consume less resources for context switching. For a register-based computer, the state of all registers must be manually saved before context switching. There are usually a large number of registers in the Proteus architecture, and the context switching requires centralized memory operations. Stack-based computers do not have these problems.

Instead of register-based architecture, it has a bigger advantage: faster. The register is located in the CPU, and the Access value is very block. Intel's new 64 processor, such as itanium, has hundreds of On-Chip registers, while stack-based processors almost always access data from memory, which is obviously slow.

Comparison table
------------------------------------------------
--------- Register-based processors for stack-based processors
------------------------------------------------
Benefits has a smaller memory usage. The basic operation is very fast.
Faster function calling (better overall performance)
Faster context switching and more transparent execution
Costs basic operations are relatively slow. Memory-intensive context switch
Work-intensive function call
------------------------------------------------