Java物理机呢？ [关闭]答案

【问题标题】：What about Java Physical Machine? [closed]Java物理机呢？ [关闭]
【发布时间】：2010-10-24 08:46:07
【问题描述】：

Java 是移动设备最重要的语言，因为它通过在字节码和机器之间插入 JVM 的虚拟层，允许在每台机器上执行相同的二进制/字节码。

我们能否为 X86/arm 构建采用字节码代替传统操作码和操作数的 Java 物理机？所以实际的操作系统可以使用 Java 构建，它比在我们当前的操作系统上安装 JVM 更高效/更快

我的猜测是它会限制安装新版本的 JVM，但许多移动设备确实支持有限版本的 JVM，所以这可能不是问题？

为什么没有人尝试在硬件上实现相同的概念？

【问题讨论】：

标签： java jvm

【解决方案1】：

这已经存在。第一次尝试是 Sun 的 PicoJava 规范，其中一个开源实现在某个时候发布。

当前可以直接运行 Java 字节码的 CPU 示例：

【讨论】：

另外，azulsystems.com 有一个生产就绪的解决方案，奇怪的是，他们要求人们跳过荒谬的圈子来获取他们产品的非常基本的信息，从而阻止人们进行调查。

【解决方案2】：

我们能造出这样的野兽吗？我们当然可以。我们也可以尝试用一根芹菜砍一棵卡里树，但这并不是一个好主意:-)

许多个月前的 Forth 也做过类似的事情（我认为它被称为 Novix）。我怀疑它会在这个特殊情况下失败，原因有很多。

创建 Java CPU 的成本将远远超过创建 Java 解释器的成本。这就是为什么没有一百万种不同的 CPU 制造商，但有一百万种不同的计算机语言（嗯，可能没有那么多，但数量很多）。
JIT 编译器消除了对 Java-in-silicon 的相当多的需求，因为它们无论如何都会编译成汇编语言。
与第 1 点相关，想象一下修复 CPU 中的错误而不是解释器中的错误的成本。除非您的 CPU 具有某种形式的可升级性（例如可替换的微码），否则事情将会变得昂贵。而且，如果您确实使用微码，那么您将失去 Java-on-silicon 的一些优势，因为您现在拥有片上解释器，而不是在常规操作系统上运行。
大量的人已经在使用具有 Java 的机器。在市场转向您的解决方案时，您将面临很多阻力。

【讨论】：

错了3。这真的取决于处理器的设计。通常，微处理器中逻辑的复杂性远比典型程序简单。与软件不同，硬件在设计过程中通常会出现严重故障。
@user148298，您可能想用谷歌搜索 cpu errata 并检查 800,000 个结果中的一些 :-) 处理器确实即使在制造后也有很多错误，而不是像很多都是软件，但我的观点是修复它们的成本通常要高得多。
@user148298，除非您在 eeprom 模型上围绕可闪存微码设计处理器，否则您无法在不重新制造的情况下修复错误。但是拥有微码模型有一些缺点，而且过去在商业上并不是很成功。

【解决方案3】：

AFAIK，这已经完成了 (see the PSC 1000 microprocessor reference manual)。引用：

PSC1000 微处理器的堆栈架构和Java虚拟机非常相似的。这只会产生一个相对简单的字节需要生成代码翻译器（20K）来自 Java 字节码的可执行本机代码，而不是比完整的即时 (JIT) 编译器 (200–400K)。这结果是 Java 程序的初始执行速度更快和显着更小的内存需求。此外，大多数现代语言都是在堆栈模型。允许 PSC1000 的功能有效地运行 Java 类似地适用于其他语言比如 C、Forth 和 Postscript..

【讨论】：

Jazelle (en.wikipedia.org/wiki/Jazelle) 也提供类似的功能。

【解决方案4】：

这样做的问题是您没有规模经济。

英特尔/AMD 处理器比您使用这些处理器获得的更便宜和更快，直到它们进入每个 cpu 中。当前基于软件的 JVM 比硬件中的 JVM 快得多，而且随着 CPU 的不断提高，没有动力移动。

时代变了。 CPU 在当前架构下并没有变得更快，所以现在也许这更有意义，因为 Java 非常适合多核应用程序。

【讨论】：

【解决方案5】：

Sun出品了几款java芯片（picoJava、ultraJava），还有this one。

【讨论】：