- #36
chiro
Science Advisor
- 4,817
- 134
The Java Virtual Machine basically executes a bunch of tokens in the same way that a CPU does.
A CPU has a token structure where the first byte corresponds to an actual instruction and based on that it grabs some other data that it needs to execute the instruction.
For example in the case of MOV AX, 8000h if I recall the opcode for this is B8 in hex for x86 systems. So the instruction would either be B8 80 00 or B8 00 80 in memory depending on the endian-ness of the system.
In the JVM, the application does the same thing except all this stuff is done by the program by basically allocating large chunks of memory and then using routines to link the virtual tokens in Java (i.e. the instructions, class definitions and so on) and basically have a general way of building up all the meta-data and scripting that a normal compiler does (i.e. parsing, structure building, and all of that) except it does it at run-time.
So think of a compiler taking the code and definitions, creating the memory layout for the structure and the instructions and then taking that static definition and turning that static code into something the OS can use.
What the JVM does is that acts as a kind of compiler where it compiles the code but instead of turning it into the tokens the OS uses it turns it into tokens it uses and has a support system that eventually has a way indirectly (or directly) of executing those tokens with code that already is in the form that OS knows.
A CPU has a token structure where the first byte corresponds to an actual instruction and based on that it grabs some other data that it needs to execute the instruction.
For example in the case of MOV AX, 8000h if I recall the opcode for this is B8 in hex for x86 systems. So the instruction would either be B8 80 00 or B8 00 80 in memory depending on the endian-ness of the system.
In the JVM, the application does the same thing except all this stuff is done by the program by basically allocating large chunks of memory and then using routines to link the virtual tokens in Java (i.e. the instructions, class definitions and so on) and basically have a general way of building up all the meta-data and scripting that a normal compiler does (i.e. parsing, structure building, and all of that) except it does it at run-time.
So think of a compiler taking the code and definitions, creating the memory layout for the structure and the instructions and then taking that static definition and turning that static code into something the OS can use.
What the JVM does is that acts as a kind of compiler where it compiles the code but instead of turning it into the tokens the OS uses it turns it into tokens it uses and has a support system that eventually has a way indirectly (or directly) of executing those tokens with code that already is in the form that OS knows.