是否有一个Java字节码优化器,可以删除无用的gotos?

hsi*_*nen 18 java optimization bytecode goto jvm-hotspot

问题:我有一个方法可以编译超过8000字节的Java字节码.HotSpot有一个神奇的限制,使得JIT不会超过8000字节的方法.(是的,有一个庞大的方法是合理的.这是一个标记器循环.)该方法在库中,我不想要求库的用户必须配置HotSpot来停用魔术限制.

观察:反编译字节码表明Eclipse Java Compiler生成了许多无意义的getos.(javac甚至更糟.)也就是说,有些只能从跳跃中获得.显然,跳转到goto的跳转应该直接跳到goto跳转的地方,goto应该被消除.

问题:是否有针对Java 5类文件的字节码优化器,可以使无意义的跳转链变平,然后删除不必要的getos?

编辑:我的意思是:

8698:   goto    8548
8701:   goto    0
Run Code Online (Sandbox Code Playgroud)

显然,第二个goto只能通过跳转到8701到达,这可能也是直接跳转到0.

在第二次调查中,这种可疑模式更为常见:

4257:   if_icmpne   4263
4260:   goto    8704
4263:   aload_0
Run Code Online (Sandbox Code Playgroud)

显然,人们希望编译器将"不等于"比较反转为"相等"比较,跳转到8704并消除goto.

Arn*_*ter 0

一种方法编译超过 8000 字节?有人看懂这段代码吗?是可测试的吗?尝试将其分成多个(私有?)具有有意义名称的方法,而不是与优化器发生冲突!

好吧,也许有一些合法的大方法。但抱歉,问题中没有任何提示。

  • 是的,我理解代码。它还比任何重新表述为递归下降方法更接近规范。是的,它可以通过大量单元测试进行测试。 (3认同)
  • 听起来他正在编写一个解析器——分词器循环变大实际上是非常合理的,而且将其保持在一起实际上“更”可读。(有人强迫我分解这样的方法,只是因为它超过了 n 行,而下个月他们抱怨说,因为它更难遵循......) (2认同)