除了可能的平台独立性实现之外，Bytecode JIT执行是否优于本机代码？
显然，使用“虚拟机”而不是字节码JIT执行的语言有几个优点。但是，这会在多大程度上影响关于本机代码和JIT执行的优缺点的讨论？
这是我确定的属性列表，问题在于它还适用于本机代码的范围 - 如果编译器支持它...
安全
VM运行时环境可以观察运行的应用程序，例如缓冲区溢出。
所以第一个问题是，如果这是由“运行时环境”完成的，意味着例如在类库中还是在JIT执行期间？
内存代码编译器也存在内存边界检查。这里有其他/一般限制吗？
优化
在本机代码编译器中也应该可以进行经典优化。在编译为本机代码之前，请参阅LLVM，它实际上使用生成的bitcode来运行优化。
也许在JIT中会出现类似动态优化的内容，例如：识别与执行上下文相关的优化事项。对于本机编译器来说，也可能生成一些代码来优化运行时的执行。但不知道是否实施了这样的事情。
受欢迎的虚拟机实现可以做到这一点 - 问题是这是否真的可以为本机代码带来真正的优势。
线程
我不会这样做，而VM中的线程也依赖于操作系统的本机Thread实现。
如果我们发现没有真正优于本机代码的优势，并且JIT总是存在运行时缺陷......那么这会导致下一个问题：
基于JIT执行的操作系统设计（例如Singularity，Cosmos，...）是否有意义？
我可能会发现一个优点：具有此设计的操作系统不需要MMU。意味着没有使用MMU的过程分离，而是软件中的对象/组件之间的分离。但它值得吗？
最好的问候; - ）
答案 0 :(得分：1)
理论上，他们可以利用他们运行的平台/ CPU来编译更快的代码。
在实践中，我个人并未遇到任何实际发生的情况。
但还有其他问题。编译成字节码的高级语言也碰巧有垃圾收集，这在某些域中非常有用。它不是因为的JIT编译器本身，但是有一个JITter实际上使它变得更容易，因为通常这种语言更易于JITter分析和计算，例如指针在堆栈上等等。