JVM 绝对不是与语言无关的，有些语言无法在其上高效实现。例如，JVM 不提供内存寻址操作，因此像 C 这样的低级语言的实现效率会非常低。但只要有适当的智能编译器，它的原语集就能够支持许多具有与 Java 不同功能的流行语言。能够像样实现的语言不一定只是带有语法糖的Java；但是当然，你与 Java 的差异越大，实现该语言就越困难
The JVM is definitely not language-agnostic, and some languages can't be implemented efficiently on it. The JVM offers no memory addressing operations, for instance, so an implementation of a lower-level language like C would be horribly inefficient. But its set of primitives is capable of supporting many popular languages with features different from Java's, given a suitably smart compiler. The languages that can be implemented decently aren't necessarily just Java with syntactic sugar; but of course the more different you get from Java, the harder it is to implement the language
In the sense that the JVM and java bytecode is turing-complete, any other turing-complete language can be transformed and compiled to java bytecode and run on the JVM. It may be horribly inefficient, but not impossible. As for the strictest possible definition of "agnostic", there is no such thing. At a hardware-level, all processors have a defined set of binary instructions they support so at some point, any language will have to be transformed to an assembly compatible with the hardware it's supposed to execute on.
EDIT: The JVM was not developed in a vacuum, it was developed in conjunction with the JAVA programming language so it stands to reason that the Java language heavily influenced the design of the Java byte-code and the JVM. So in that sense, you could say that the JVM was designed with Java in mind. But it is also true that in the architecture, the JVM was consciously de-coupled from the Java language (through the intermediate bytecode format) so there are elements in the design that takes possible alternative languages into account.
The JVM is not language-agnostic; however, it's language is JVM bytecode. Consider that the assembly of the virtual machine and then you'll have a good idea of what the JVM runs. JVM bytecode was selected to facilitate running Java programs, but like any "complete enough" assembly, it can be used for many other things. The key is what's being done in the compilation process.
Other language barriers include the design that the JVM is a stack based machine, which means explicit addresses are nonsense to the JVM in the bytecode layer. There's no "load" or "store" operations; however, that doesn't stop people who want to implement languages that do addressing on the JVM. It just makes it harder for those who want to do addressing.
To do addressing on the JVM, you basically write a simulator; where you have an object containing the "address to object handle" lookup table. This allows you to do rudimentary addressing via simulation on a virtual machine that lacks addressing. It's not always pretty, and the quality of the simulation is only typically extended to the use cases that the simulated language would permit.
Yes, you do lose a bit of performance doing Address(the object) to Map(of object to Java heap reference) to (internally in the JVM) java heap reference to physical memory address. But that's what has to be done to keep the platform agnostic. If you had direct memory access, you would eventually be pushed into coding for different hardware platforms instead of coding for the virtual machine. Well, at least you would be pushed into platform specific code much earlier than occurs these days.
发布评论
评论（4）
JVM 绝对不是与语言无关的，有些语言无法在其上高效实现。例如，JVM 不提供内存寻址操作，因此像 C 这样的低级语言的实现效率会非常低。但只要有适当的智能编译器，它的原语集就能够支持许多具有与 Java 不同功能的流行语言。能够像样实现的语言不一定只是带有语法糖的Java；但是当然，你与 Java 的差异越大，实现该语言就越困难
The JVM is definitely not language-agnostic, and some languages can't be implemented efficiently on it. The JVM offers no memory addressing operations, for instance, so an implementation of a lower-level language like C would be horribly inefficient. But its set of primitives is capable of supporting many popular languages with features different from Java's, given a suitably smart compiler. The languages that can be implemented decently aren't necessarily just Java with syntactic sugar; but of course the more different you get from Java, the harder it is to implement the language
从JVM和java字节码是图灵完备的意义上来说，任何其他图灵完备的语言都可以转换并编译为java字节码并在JVM上运行。这可能效率极低，但并非不可能。至于“不可知论者”最严格的定义，并不存在这样的事情。在硬件级别，所有处理器都有一组定义的它们支持的二进制指令，因此在某些时候，任何语言都必须转换为与其应该执行的硬件兼容的汇编语言。
编辑：
JVM 并不是凭空开发的，它是与 JAVA 编程语言一起开发的，因此 Java 语言对 Java 字节码和 JVM 的设计产生了很大的影响。因此，从这个意义上说，您可以说 JVM 是在设计时考虑到 Java 的。但在架构中，JVM 有意识地与 Java 语言解耦（通过中间字节码格式）也是事实，因此设计中的某些元素考虑了可能的替代语言。
In the sense that the JVM and java bytecode is turing-complete, any other turing-complete language can be transformed and compiled to java bytecode and run on the JVM. It may be horribly inefficient, but not impossible. As for the strictest possible definition of "agnostic", there is no such thing. At a hardware-level, all processors have a defined set of binary instructions they support so at some point, any language will have to be transformed to an assembly compatible with the hardware it's supposed to execute on.
EDIT:
The JVM was not developed in a vacuum, it was developed in conjunction with the JAVA programming language so it stands to reason that the Java language heavily influenced the design of the Java byte-code and the JVM. So in that sense, you could say that the JVM was designed with Java in mind. But it is also true that in the architecture, the JVM was consciously de-coupled from the Java language (through the intermediate bytecode format) so there are elements in the design that takes possible alternative languages into account.
JVM 与语言无关；然而，它的语言是 JVM 字节码。考虑一下虚拟机的组装，然后您就会很好地了解 JVM 运行的内容。选择 JVM 字节码是为了方便运行 Java 程序，但与任何“足够完整”的程序集一样，它还可以用于许多其他用途。关键是编译过程中做了什么。
其他语言障碍包括 JVM 是基于堆栈的机器的设计，这意味着显式地址对于字节码层中的 JVM 来说是无意义的。没有“加载”或“存储”操作；然而，这并不能阻止人们想要实现在 JVM 上寻址的语言。它只会让那些想要寻址的人变得更加困难。
要在 JVM 上进行寻址，您基本上需要编写一个模拟器；其中您有一个包含“对象句柄地址”查找表的对象。这允许您通过在缺乏寻址的虚拟机上进行模拟来进行基本寻址。它并不总是那么漂亮，并且模拟的质量通常仅扩展到模拟语言允许的用例。
是的，将 Address（对象）映射（对象到 Java 堆引用）映射到（在 JVM 内部）对物理内存地址的 java 堆引用，确实会损失一些性能。但这是保持平台不可知性所必须要做的。如果您可以直接访问内存，那么您最终将被迫为不同的硬件平台编码，而不是为虚拟机编码。好吧，至少你会比现在更早地进入特定于平台的代码。
The JVM is not language-agnostic; however, it's language is JVM bytecode. Consider that the assembly of the virtual machine and then you'll have a good idea of what the JVM runs. JVM bytecode was selected to facilitate running Java programs, but like any "complete enough" assembly, it can be used for many other things. The key is what's being done in the compilation process.
Other language barriers include the design that the JVM is a stack based machine, which means explicit addresses are nonsense to the JVM in the bytecode layer. There's no "load" or "store" operations; however, that doesn't stop people who want to implement languages that do addressing on the JVM. It just makes it harder for those who want to do addressing.
To do addressing on the JVM, you basically write a simulator; where you have an object containing the "address to object handle" lookup table. This allows you to do rudimentary addressing via simulation on a virtual machine that lacks addressing. It's not always pretty, and the quality of the simulation is only typically extended to the use cases that the simulated language would permit.
Yes, you do lose a bit of performance doing Address(the object) to Map(of object to Java heap reference) to (internally in the JVM) java heap reference to physical memory address. But that's what has to be done to keep the platform agnostic. If you had direct memory access, you would eventually be pushed into coding for different hardware platforms instead of coding for the virtual machine. Well, at least you would be pushed into platform specific code much earlier than occurs these days.
忽略内置的 OOP 指令，某些语言更适合基于寄存器的 VM（如 parrot），而不是基于堆栈的 VM（如 JVM）。
本文很好地讨论了这个问题： http://db.usenix.org/ events/vee05/full_papers/p153-yunhe.pdf
Ignoring the builtin OOP instructions some languages are better suited for a register based VM (like parrot) instead of a stack based VM (like JVM).
This paper covers the issue nicely: http://db.usenix.org/events/vee05/full_papers/p153-yunhe.pdf