What about Java Physical Machine? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

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

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.

Answer 2

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

Answer 3

Can we build such a beast? Sure, we can. We can also try to cut down a Karri tree with a stick of celery, but that doesn't make it a good idea :-)

A similar thing was done with Forth many moons ago (Novix, I think it was called). I suspect it would fail in this particular case 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, but there are a million different computer languages (well, maybe not that many, but it's a lot).

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. Unless you have some form of upgradability in your CPU (such as replacable microcode), things are going to get expensive. And, if you do use microcode, you've lost some of the advantages of Java-on-silicon since you now have an interpreter on-chip rather than running on a regualr operating system.

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 4

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 5

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