当目标平台预先确定时，如何消除 JIT 的需要？
使用中间语言（.Net：MSIL，Java：字节码）我们可以实现平台独立性，这真是太好了。但是，当应用程序应该仅在单个平台（例如Windows）上运行时，在这种情况下是否有任何简单的方法来指定“我不需要每次都需要JIT，只需给我本机代码即可”？
It is great that using Intermediate Language (.Net: MSIL, Java: Bytecode) we can achieve platform independence. But when an application is supposed to run on a single platform only (e.g. Windows), in that case is there any simple way to specify that "I don't need JIT every time just give me the native code."?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
单一平台（Windows）并不真正意味着单一目标。我目前在 Windows 上运行 - 有些二进制文件是 x86，有些是 x64。即使在同一处理器系列中，不同的特定芯片也具有 JIT 可以处理的不同功能。
在 .NET 上，您可以使用NGEN -但就我个人而言，在实际在生产中使用它之前，我会先看看它有多少好处。我相信主要的好处是启动时间而不是实际执行时的性能。事实上，我相信“正常”JIT 可以进行一些 NGEN 无法进行的优化。
需要注意的一点是，虽然正如 Dolda2000 提到的那样，Java 的 Hotspot JIT 是自适应的，但 .NET JIT 目前“仅一次”——如果它事实证明被大量使用，或者围绕子类化做出假设，然后稍后“撤消”它们。
Single platform (Windows) doesn't really mean single target. I'm currently running on Windows - and some binaries are x86, and some are x64. Even within the same processor family, different specific chips have different abilities that the JIT could take care of.
On .NET you can use NGEN - but personally I would see how much benefit there is before you actually use it in production. I believe the main benefit is in terms of start-up time rather than performance when actually executing. In fact, I believe there are some optimizations that the "normal" JIT can make which NGEN won't.
One point to note is that although the Hotspot JIT for Java is adaptive as Dolda2000 mentions, the .NET JIT is currently "once only" - it won't re-JIT code putting in more effort if it turns out to be very heavily used, or make assumptions around subclassing and then "undo" them later.
我不能代表 .Net，但肯定有本地 Java 编译器，例如 GNU GCJ。
然而，更重要的是，您真的确定想要避免 JIT 吗？ JIT 编译器根据代码全局状态的知识进行操作，通常可以进行静态编译器无法进行的优化。例如，当 JIT 编译器知道当前不存在覆盖它的子类时，它可以内联虚拟方法（而静态编译器无法知道这样的类是否会（静态或动态）链接到稍后）。还有很多其他的例子，但我认为这个答案的范围不是列出它们。 :)
I cannot speak for .Net, but there certainly are native Java compilers, such as GNU GCJ.
More importantly, however, are you really sure that you want to avoid JITing? A JIT compiler, operating as it is on knowledge of the global state of the code, can often make optimizations that static compilers cannot. For example, a JIT compiler can inline virtual methods when it knows that no subclass currently exists that overrides it (whereas a static compiler couldn't know if such a class would be (statically or dynamically) linked in later on). There are many other examples as well, but I don't think the scope of this answer is to list them. :)
另一点：
许多当前的框架在类加载期间操作字节码。这意味着磁盘上的代码不是执行的代码。任何基于注释的依赖注入的 Java 框架都会使用它。 JPA/Hibernate 使用这个。 AOP（面向方面编程）通常使用它，尽管 AOP 框架通常还提供了一种在构建期间操作类文件的方法。
预先将代码编译为本机代码将使这些框架变得毫无用处。
Another point:
Many current frameworks manipulate the bytecode during classloading. This means that the code on disk is not the code executed. Any Java Framework doing annotation based dependency injection will use this. JPA/Hibernate use this. AOP (Aspect Oriented Programming) usually use this, although the AOP frameworks usually also provide a way to manipulate the class files during the build.
Compiling the code upfront into native code would render these frameworks useless.