What about Java Physical Machine ?

Question

Java is most important language for mobile devices as it allows the same binary/byte code to be executed on every machine by inserting virtual layer of JVM between byte code and machine.

Can we build Java Physical Machine which will take byte code instead of traditional opcode and operand for X86/arm ? so the Actual Operating System Can be built using Java and it will be efficient/fast than installing JVM over our current operating system

My guess is it will restrict installing new version of JVM but many mobile devices do support limited version of JVM so that may not be the issue ?

Why anybody has not tried to implement same concepts to hardware ?

Answer 1

A similar thing was done with Forth many moons ago (Novix, I think it was called). I suspect it would fail for a number of reasons.

1. The cost of creating a Java CPU would far outweigh the cost of creating a Java interpreter. That's why there aren't a million different CPU fabricators.
2. JIT compilers remove quite a bit of the need for Java-in-silicon since they compile to assembly language anyway.
3. Related to point 1, imagine the cost of fixing a bug in your CPU as opposed to one in your interpreter.
4. A vast number of people already use machines that have Java. You going to face a lot of resistance to the market moving to your solution.

Answer 2

AFAIK, this has already been done (see the PSC 1000 microprocessor reference manual). Quote:

The stack architectures of the PSC1000 microprocessor and the Java Virtual Machine are very similar. This results in only a relatively simple byte code translator (20K) being required to produce executable native code from Java byte code, rather than a full Just-in-Time (JIT) compiler (200–400K). The result is much faster initial execution of Java programs and significantly smaller memory requirements. Further, most modern languages are implemented on a stack model. The features that allow the PSC1000 to run Java efficiently apply similarly to other languages such as C, Forth and Postscript..

Answer 3

This already exists. The first attempt was Sun's PicoJava specification, of which an open source implementation was released at some point.

Current examples of CPUs that can directly run Java bytecode:

• aJile: http://www.ajile.com/
• Imsys: http://www.imsystech.com/
• ARM with Jazelle extensions
• JOP: http://www.jopdesign.com/index.jsp

Answer 4

Sun has produced a few java chips (picoJava, ultraJava), and there is this one.

Answer 5

The problem with this is that you don't have the economies of scale.

The Intel/AMD processors are much cheaper and faster than what you can get with these until they go in every cpu everywhere. The current softwarebased JVMs are simply much faster than what could be gotten in hardware, and as the CPU's kept getting faster there was no incentive to move.

Times have changed. CPU's don't get any faster with the current architecture, so perhaps this makes more sense now, as Java is well suited for multi-core applications.