What about Java Physical Machine?(Java物理机呢?)
问题描述
Java 是移动设备最重要的语言,因为它通过在字节码和机器之间插入 JVM 虚拟层,允许在每台机器上执行相同的二进制/字节码.
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.
我们能否为 X86/arm 构建采用字节码代替传统操作码和操作数的 Java 物理机?所以实际的操作系统可以使用 Java 构建,它比在我们当前的操作系统上安装 JVM 更高效/更快
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
我的猜测是它会限制安装新版本的 JVM,但许多移动设备确实支持有限版本的 JVM,所以这可能不是问题?
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 ?
推荐答案
我们能造出这样的野兽吗?我们当然可以.我们也可以尝试用一根芹菜砍一棵卡里树,但这并不是一个好主意:-)
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 :-)
许多个月前的 Forth 也做过类似的事情(我认为它被称为 Novix).我怀疑它会在 这个 特殊情况下失败,原因有很多.
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.
创建 Java CPU 的成本将远远超过创建 Java 解释器的成本.这就是为什么没有一百万种不同的 CPU 制造商,但有一百万种不同的计算机语言(嗯,也许没有那么多,但数量很多).
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).
JIT 编译器在很大程度上消除了对 Java-in-silicon 的需求,因为它们无论如何都会编译成汇编语言.
JIT compilers remove quite a bit of the need for Java-in-silicon since they compile to assembly language anyway.
与第 1 点相关,想象一下修复 CPU 中的错误而不是解释器中的错误的成本.除非您的 CPU 具有某种形式的可升级性(例如可替换的微码),否则事情将会变得昂贵.而且,如果您确实使用微代码,那么您将失去 Java-on-silicon 的一些优势,因为您现在在芯片上拥有解释器,而不是在常规操作系统上运行.
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.
很多人已经在使用装有 Java 的机器.在市场转向您的解决方案时,您将面临很多阻力.
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.
这篇关于Java物理机呢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:Java物理机呢?
基础教程推荐
- 设置 bean 时出现 Nullpointerexception 2022-01-01
- 无法使用修饰符“public final"访问 java.util.Ha 2022-01-01
- 减少 JVM 暂停时间 >1 秒使用 UseConcMarkSweepGC 2022-01-01
- Java Keytool 导入证书后出错,"keytool error: java.io.FileNotFoundException &拒绝访问" 2022-01-01
- FirebaseListAdapter 不推送聊天应用程序的单个项目 - Firebase-Ui 3.1 2022-01-01
- 如何使用 Java 创建 X509 证书? 2022-01-01
- 在 Libgdx 中处理屏幕的正确方法 2022-01-01
- Java:带有char数组的println给出乱码 2022-01-01
- “未找到匹配项"使用 matcher 的 group 方法时 2022-01-01
- 降序排序:Java Map 2022-01-01