Oracle和Eclipse编译器生成的java字节码的差异 [英] Differences in java bytecode produced by Oracle's and Eclipse's compilers

查看:139
本文介绍了Oracle和Eclipse编译器生成的java字节码的差异的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的项目执行一些Java字节码检测。我们偶然发现了一些奇怪的行为。假设以下代码片段:

Our project does some Java bytecode instrumentation. And we stumbled upon some strange behavior. Suppose the following code snippet:

  public void a() {
    new Integer(2);
  }

Oracle的javac将以上字节码编译成以下字节码:

Oracle's javac compiles the above into the following bytecode:

   0:   new #2; //class java/lang/Integer
   3:   dup
   4:   iconst_2
   5:   invokespecial   #3; //Method java/lang/Integer."<init>":(I)V
   8:   pop
   9:   return

和Eclipse的编译器进入:

and Eclipse's compiler into:

   0:   new #15; //class java/lang/Integer
   3:   iconst_2
   4:   invokespecial   #17; //Method java/lang/Integer."<init>":(I)V
   7:   return

如您所见,Oracle编译器在new之后生成dup,而Eclipse则不然。在这个用例中完全正确,因为根本不使用新创建的Integer实例,因此不需要dup。

As you can see, Oracle compiler produces "dup" after "new", whereas Eclipse doesn't. Which is totally correct in this use case, as newly created Integer instance is not used at all, so no "dup" is required.

我的问题是:


  1. 是否对不同编译器之间的差异有一些概述?文章/博客文章?

  2. 我能否安全地得出结论,如果new和invokespecial之间没有dup,那么在初始化之后不会使用对象?


推荐答案



  1. 我能否安全地得出结论,如果new和invokespecial之间没有dup,那么在初始化后没有使用对象?


我不确定你的意思完全,但是对于创建的对象的引用可能会被构造函数存储在某处。因此,调用方法可能在初始化后不使用该对象,但该对象可能仍然可以访问,因此可能不是垃圾回收。

I'm not sure what you mean exactly, but a reference to the created object might be stored somewhere by the constructor. Therefore the calling method might not use the object after initialization but the object might still be reachable and might be not garbage collectable therefore.

这篇关于Oracle和Eclipse编译器生成的java字节码的差异的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆