Was ist mit Java Physical Machine?

Question

Java ist die wichtigste Sprache für mobile Geräte, da sie die Ausführung desselben Binär-/Byte-Codes auf jeder Maschine ermöglicht, indem die virtuelle Schicht der JVM zwischen Byte-Code und Maschine eingefügt wird.

Können wir Java Physical Machine, die Byte-Code anstelle der traditionellen Opcode und Operand für X86 / Arm nehmen wird bauen? so dass die Actual Operating System kann mit Java gebaut werden und es wird effizient / schnell als die Installation von JVM über unsere aktuelle Betriebssystem sein

Ich vermute, dass es die Installation der neuen JVM-Version einschränken wird, aber viele mobile Geräte unterstützen eine eingeschränkte JVM-Version, so dass dies möglicherweise nicht das Problem ist.

Warum hat niemand versucht, die gleichen Konzepte in Hardware zu implementieren?

Answer 1

Das gibt es bereits. Der erste Versuch war Sun's PicoJava Spezifikation, von der irgendwann eine Open-Source-Implementierung veröffentlicht wurde.

Aktuelle Beispiele für CPUs, die Java-Bytecode direkt ausführen können:

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

Answer 2

Können wir so ein Biest bauen? Sicher, das können wir. Wir können auch versuchen, einen Karri-Baum mit einer Selleriestange zu fällen, aber das macht es nicht zu einer guten Idee :-)

Etwas Ähnliches wurde mit Forth gemacht viele (Novix, glaube ich, hieß es). Ich vermute, es würde in este besonderen Fall aus einer Reihe von Gründen.

1. Die Kosten für die Entwicklung einer Java-CPU würden die Kosten für die Entwicklung eines Java-Interpreters bei weitem übersteigen. Aus diesem Grund gibt es nicht eine Million verschiedener CPU-Hersteller, sondern son eine Million verschiedene Computersprachen (na ja, vielleicht nicht so viele, aber doch eine ganze Menge).

2. JIT-Compiler machen Java-in-Silicon zum großen Teil überflüssig, da sie ohnehin in Assembler kompilieren.

3. Stellen Sie sich, bezogen auf Punkt 1, die Kosten für die Behebung eines Fehlers in Ihrer CPU im Vergleich zu einem Fehler in Ihrem Interpreter vor. Wenn Sie Ihre CPU nicht in irgendeiner Form aufrüstbar machen können (z. B. durch austauschbaren Mikrocode), wird es teuer werden. Und wenn Sie tun Microcode verwenden, gehen einige der Vorteile von Java-on-Silicon verloren, da der Interpreter nun auf dem Chip und nicht mehr auf einem normalen Betriebssystem läuft.

4. Eine große Anzahl von Menschen benutzt bereits Geräte mit Java. Sie werden mit einer Los des Widerstands gegen die Umstellung des Marktes auf Ihre Lösung.

Answer 3

AFAIK wurde dies bereits getan ( siehe das Referenzhandbuch für den Mikroprozessor PSC 1000 ). Zitat:

Die Stack-Architekturen des PSC1000-Mikroprozessors und der Java Virtual Machine sind sich sehr ähnlich. Dies führt nur zu einer relativen Code-Übersetzer (20K) erforderlich ist, um eine ausführbaren nativen Code aus Java-Bytecode zu erzeugen, anstatt statt eines vollständigen Just-in-Time (JIT)-Compilers (200-400K). Das Ergebnis ist eine viel schnellere anfängliche Ausführung von Java-Programmen und deutlich geringere Speicheranforderungen. Außerdem sind die meisten modernen Sprachen auf einem Stapelmodell implementiert. Die Funktionen, die es der PSC1000 ermöglichen die effiziente Ausführung von Java ermöglichen, gelten in ähnlicher Weise für andere Sprachen wie z.B. C, Forth und Postscript.

Answer 4

Das Problem dabei ist, dass man keine Größenvorteile hat.

Die Intel/AMD-Prozessoren sind viel billiger und schneller als das, was Sie mit diesen bekommen können, bis sie in jedem CPU überall gehen. Die aktuellen softwarebasierten JVMs sind einfach viel schneller als das, was man in Hardware bekommen kann, und da die CPUs immer schneller wurden, gab es keinen Anreiz, sich zu bewegen.

Die Zeiten haben sich geändert. Die CPUs werden mit der aktuellen Architektur nicht schneller, so dass dies jetzt vielleicht mehr Sinn macht, da Java gut für Multicore-Anwendungen geeignet ist.

Answer 5

Sun hat einige Java-Chips hergestellt (picoJava, ultraJava), und es gibt celui-ci .