13

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 ?

Xinus
  • 29,617
  • 32
  • 119
  • 165

5 Answers5

14

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:

Grodriguez
  • 21,501
  • 10
  • 63
  • 107
  • Also, http://www.azulsystems.com/ have a production-ready solution, which they strangely enough discourage people from investigating by requiring them to jump through ridiculous hoops to get even very basic information of their products. – Mikael Gueck Oct 24 '10 at 09:52
8

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.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • 2
    Wrong on 3. It really depends on the design of the processor. Generally, the complexity of the logic in a microprocessor is far simpler than a typical program. Unlike software, hardware typically fails spectacularly during the design process. – ATL_DEV Dec 10 '12 at 07:16
  • @user148298, you may want to google `cpu errata` and examine some of the 800,000 results of that :-) Processors _do_ get plenty of bugs even after manufacture, not as many as software, but my point is the cost to fix them is generally much more significant. – paxdiablo Dec 10 '12 at 07:40
  • @user148298, Unless you design your processor around a flashable microcode on an eeprom model you cannot fix bugs without re-fabrication. But having a microcode model has dis-advantages and has not been very commercially successful in the past. – Asad Hasan May 04 '14 at 16:54
1

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..

Niki
  • 15,662
  • 5
  • 48
  • 74
  • Jazelle (http://en.wikipedia.org/wiki/Jazelle) provides similar functionality as well. – ide Oct 24 '10 at 08:56
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.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
0

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

Maurice Perry
  • 32,610
  • 9
  • 70
  • 97