除了可移植性之外，字节码 JIT 执行相对于本机代码还有什么真正的优势吗？ （一般和操作系统设计）
除了可能实现平台独立性之外，字节码 JIT 执行相对于本机代码还有什么真正的优势吗？
显然，使用“虚拟机”而不是字节码 JIT 执行的语言有几个优点。但这在多大程度上会真正影响有关本机代码和 JIT 执行的优点/缺点的讨论？
这是我确定的属性列表，问题是这在多大程度上也适用于本机代码 - 如果编译器支持它......
安全性
VM运行时环境可以观察正在运行的应用程序，例如缓冲区溢出。
所以第一个问题是，这是否是由“运行时环境”完成的，例如通过类库或 JIT 执行期间完成的？
本机代码编译器也存在内存边界检查。这里还有其他/一般限制吗？
优化
经典优化也应该可以在本机代码编译器中实现。请参阅 LLVM，它实际上在编译为本机代码之前使用生成的位码来运行优化。
也许 JIT 中会有动态优化之类的东西，例如识别与执行上下文相关的要优化的内容。本机编译器也可能生成一些代码来优化运行时的执行。但不知道是否实现了这样的东西。
流行的 VM 实现会这样做 - 问题是这是否真的能成为优于本机代码的真正优势。
线程
我不知道这一点，而虚拟机中的线程也依赖于操作系统的本机线程实现。
如果我们发现相对于本机代码没有真正的优势，并且 JIT 总是存在运行时缺陷……那么这就会引出下一个问题：
操作系统设计是否基于 JIT 执行（例如 Singularity、Cosmos 等）。 .) 有道理吗？
我也许可以找出一个优点：采用这种设计的操作系统不需要 MMU。意味着不存在使用 MMU 的进程分离，而是软件中的对象/组件之间的分离。但这值得吗？
此致 ;-）
Is there any real advantage from Bytecode JIT execution over native code beside possible implementation of platform independency?
Apparently languages that use "virtual machines" over Bytecode JIT execution are attributed several advantages. But in what extend would this really affect a discussion concerning advantages/disadvantages of native code and JIT execution?
Here's a list of attributes that I identify, the question is in what extend does this also apply to native code - if the compiler supports it...
Security
VM runtime environments can observe the running application for e.g. buffer overflows.
So first question is if this is done by the "runtime environment", means e.g. by the class library or during JIT execution?
Memory bounds-checking exist also for native code compilers. Any other/general restrictions here?
Optimization
Classical optimization should be possible in native code compilers, too. See LLVM which in fact uses the generated bitcode to run optimization on, before compiling to native code.
Maybe there would be something like a dynamic optimization in JIT by e.g. identifying things to optimize related to the execution context. Could maybe be possible for a native compiler, too, to generate some code to optimize the execution during runtime. But dont't know if something like this is implemented.
Popular VM implementations do this - the question is if this really excuses a real advantages over native code.
Threading
I don't cound this while threading also in a VM is dependent on the native Thread implementation of the OS.
If we identify that there is no real advantage over native code and that there is always a runtime drawback in JIT... than this leads to the next question:
Does an operating system design based on JIT execution (e.g. Singularity, Cosmos, ...) make sense?
I could maybe identify one advantages: An OS with this design needs no MMU. Means there is no process seperation that makes use of the MMU, but a seperation between objects/components in software. But is it worth it?
Best regards ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理论上，他们可以利用其运行的平台/CPU 来编译更快的代码。
在实践中，我个人还没有遇到过真正发生这种情况的案例。
但还有其他问题。编译为字节码的高级语言也恰好具有垃圾收集功能，这在某些领域非常有用。这并不是因为 JIT 编译器本身，而是拥有 JITter 实际上使事情变得更加容易，因为 JITter 通常更容易分析和计算出语言，例如指针在堆栈上的位置等。
Theoretically, they could take advantage of the platform/CPU they run on, to compile faster code.
In practice, I personally haven't come across any case in which that actually happens.
But there's also other issues. Higher-level languages that compile into bytecode also happen to have garbage collection, which is very useful in some domains. It's not because of the JIT compiler per se, but having a JITter makes it a lot easier practically because often the language is easier for a JITter to analyze and figure out e.g. where pointers go on the stack, etc.