为什么 JSR/RET 不推荐使用 Java 字节码？

Question

有谁知道为什么 JSR/RET 字节码对在 Java 6 中被弃用？

我在网上找到的唯一有意义的解释是，它们使运行时的代码分析变得更加困难且执行速度更慢。有谁知道还有什么原因吗？

Answer 1

JSR 和 RET 使字节码验证变得更加困难，因为放宽了一些正常字节码约束（例如在进入 JSR 时具有一致的堆栈形状）。 优点非常小（在某些情况下可能会稍小一些），并且验证器处理奇怪的 JSR/RET 模式（以及潜在的安全漏洞，以及完整验证的相关运行时成本）的持续困难使其成为一个无用的功能继续拥有。

堆栈映射和由于数据而启用的轻量级验证器在类加载过程中取得了巨大的性能优势，而且不牺牲安全性。

Answer 2

使用它们来混淆字节码的人解释一下为什么：

在处理打字问题时，

jsr

-

ret

构造特别难以处理，因为每个子例程 可以从多个地方调用，需要合并类型信息，因此更保守 估计[需要产生]。此外，反编译器通常会期望为每个

ret

找到特定的

jsr

。

最后一句仅与混淆器相关（例如基于

soot

的 JBCO），它甚至不放置

ret

而是

pop

返回地址，模拟 goto。 15 年后，对于一些“现代”反编译器来说，这仍然足够有效：

org.benf.cfr.reader.util.ConfusedCFRException: Missing node tying up JSR block

抛开这个技巧不谈，引文的第一部分说，（即使）如果“按最初设计”使用，

jsr

会导致（数据流）分析速度减慢。 （字节码验证器是一个数据流分析器，请参阅 Leroy 进行深入讨论——在此处命名抽象解释之前我应该停下来，尽管这[概念上]也涉及字节码验证......

第一个 JVM 字节码验证算法是由 Sun 的 Gosling 和 Yellin 提出的 [...]。 几乎所有现有的字节码验证器都实现了该算法。可以概括为数据流 分析应用于虚拟机的类型级抽象解释。