3

I was reading about instruction set in wiki and I came across this paragraph:

Some virtual machines that support bytecode as their ISA such as Smalltalk, the Java virtual machine, and Microsoft's Common Language Runtime, implement this by translatin the bytecode for commonly used code paths into native machine code. In addition, these virtual machines execute less frequently used code paths by interpretation (see: Just-in-time compilation). Transmeta implemented the x86 instruction set atop VLIW processors in this fashion.

What does this exactly mean? is the bytecodes are ISA for JVM and JVM in-turn support ISA of processors.

trashgod
  • 203,806
  • 29
  • 246
  • 1,045
brain storm
  • 30,124
  • 69
  • 225
  • 393

3 Answers3

11

Yes, it is as you guessed. The JVM/JRE uses Java bytecode as its instruction set and each JVM needs to be compiled on and be runnable on the native/local hardware (and therefore the local instruction set). This diagram from Wikipedia illustrates this well I think:

enter image description here

The JRE/JVM needs to be compiled for the specific hardware it runs on, though the Java bytecode definitions and interpretations by the JVM itself stay the same. As you point out, the Java bytecode can be seen as a kind of abstraction layer between the Java source code and the local machine/binary code. It does allow for a separation of concerns between the typical Java programmer and needing to know anything machine-specific, as almost all of that is handled by the JVM/JRE.

Martin Dinov
  • 8,757
  • 3
  • 29
  • 41
  • I wouldn’t place “Java APIs” below the JVM components as most of the Java APIs is implemented in Java and goes through the same chain as the application code. – Holger Jan 20 '14 at 09:45
3

is the bytecodes are ISA for JVM

The byte code is the JVMs instructions.

and JVM in-turn support ISA of processors.

but the real processor does the real work, so the JVM turns these into native instructions. First it does it interperated which is simple, but slower to execute and once the code is optimised (which is expensive) the code runs fast as raw native instructions.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
3

The JVM basically simulates a CPU for a Java program. Just as a CPU executes assembled opcodes natively on the hardware, the JVM executes Java opcodes, but strictly in software.

What does this exactly mean? is the bytecodes are ISA for JVM and JVM in-turn support ISA of processors.

An ISA (Instruction Set Architecture) specifies the entire set of disciplines and techniques that apply to writing low-level software that runs directly on the CPU. It includes a set of opcodes, which are uncomposable direct CPU commands. The JVM recognizes its own set of bytecodes (i.e. 8-bit opcodes) that direct the JVM to carry out interpreter-primitive instructions. So, yes, the bytecode specification makes up part of the JVM's ISA.

The JVM iterates through the list of opcodes executing them one by one using its own memory to emulate hardware components (e.g. stack, register, main memory) and using primitive arithmetic and logic operations to emulate the ALU. These emulated components also make up the JVM's ISA. This is the basic construction of any interpreter, give or take. However, to improve the runtime of Java applications, the JVM compiles "hotspots" to machine-specific code for optimal performance. Hotspots are sections of the code that are ran frequently. This is known as "Just-In-Time" compilation, and can be done while the program is executing. This technique brings Java's performance a lot closer to that of compiled languages. JIT is used in the .NET framework as well.

Each operating system has its own JVM implementation, which may also vary by the device's ISA. For example, you may have a JVM written for Linux-Arm, Linux-x86, or Windows-x86. The JVM itself may be written in a platform-independent (sort of anyway) language like C, but its JIT compiler must support compilation to the device's instruction set.

blackcompe
  • 3,180
  • 16
  • 27
  • writing a JVM for a new processor will be hard I guess, one deal to with ISA for processor on one hand and bytecodes on the other hand! – brain storm Jan 17 '14 at 21:33
  • @user1988876: Umm... yes you could say that :) Perhaps with a team of sophisticated developers it wouldn't be so bad. Designing the language itself is the hard part. – blackcompe Jan 17 '14 at 21:42
  • 1
    @user1988876: Implementing an interpreter or JIT compiler for the byte code is not that hard as you only have to translate about 200 instructions. But making it actually work implies implementing an object model, memory management, threading and synchronization, the low level I/O parts, and some more. That’ll turn out to be a lot of stuff, eating up the enthusiasm initially created when seeing how easy the byte code part was. – Holger Jan 20 '14 at 09:50
  • Sorry, factually incorrect. The JVM does not, in any sense "simulate a CPU" and bytecode is not the instructions for a pretend processor. I've downvoted this, but you should consider deleting your answer, because as it stands, it is simply not true. – kittylyst Nov 18 '14 at 16:48