JVM规范中JSR / RET的状态 [英] Status of JSR/RET in JVM spec

问题描述

JVM规范的某些部分建议操作 JSR（Jump SubRoutine）， JSR_W（Jump SubRoutine Wide）和 RET（从子程序返回）只能用于类文件版本50.0（JDK 1.6）：

There are some parts of the JVM specification which suggest that the operations JSR (Jump SubRoutine), JSR_W (Jump SubRoutine Wide) and RET (RETurn from subroutine) may be used only up to class file version 50.0 (JDK 1.6):

3.13最后编译

（本节假设编译器生成版本号为50.0或更低版本的类文件，因此可以使用jsr指令。参见§4.10.2 .5 。）

(This section assumes a compiler generates class files with version number 50.0 or below, so that the jsr instruction may be used. See also §4.10.2.5.)

以后：

< STRONG> 4.10.2.5。例外和最后

要实现，请尝试 - finally 构造，Java编程语言的编译器，生成带有版本号的 class 文件50.0或更低版本可以使用异常处理功能和两条特殊指令： jsr （跳转到子程序）和 ret （从子程序返回）。

To implement the try-finally construct, a compiler for the Java programming language that generates class files with version number 50.0 or below may use the exception-handling facilities together with two special instructions: jsr ("jump to subroutine") and ret ("return from subroutine").

另一方面，操作码描述本身并未说明这些功能的弃用。引用的文本只说明过去50.0版本的版本，但在此之后并没有明确说明事态。

On the other hand, the opcode descriptions themselves say nothing about a deprecation of these features. And the quoted texts only say how things used to be in versions up to 50.0, but doesn't explicitely state the state of affairs after that.

此评论（询问有关此弃用或删除背后动机的问题）表示类似的混乱程度，所以显然我不是唯一一个想要这样的人。

This comment (to a question which asks about the motivation behind this deprecation or removal) indicates a similar level of confusion, so apparently I'm not the only one looking for this.

推荐答案

在添加链接到我的时候问题，我注意到 §4.10.1.9：类型检查说明 。所以这表明新的基于strackframe的类型验证方案无法处理它们，并且 §4.10：类文件验证 写道：

While adding links to my question, I noticed that the opcodes in question are absent from §4.10.1.9: Type Checking Instructions. So this shows that the new strackframe-based type verification scheme can't handle them, and §4.10: Verification of class Files writes:

必须使用类型检查进行验证来验证版本号大于或等于50.0的 class 文件。

或者在 §4.10.1：按类型检查进行验证 ：

版本号为50.0或更高的类文件（§4.1）必须使用本节中给出的类型检查规则进行验证。

A class file whose version number is 50.0 or above (§4.1) must be verified using the type checking rules given in this section.

当且仅当 class file'时版本号等于50.0，那么如果类型检查失败，Java虚拟机实现可以选择尝试通过类型推断来执行验证（§4.10.2）。

If, and only if, a class file's version number equals 50.0, then if the type checking fails, a Java Virtual Machine implementation may choose to attempt to perform verification by type inference (§4.10.2).

所以我说版本50.0类可能仍然包含 jsr 和 ret ，但是运行JVM实现的风险将不会验证所述类，因此将无法加载它。

So I'd say a version 50.0 class may still contain jsr and ret, but runs some risk that a JVM implementation won't verify said class and as a consequence will fail loading it.

然后我在 §4.9.1：静态约束 ：

只有§6.5可能出现在代码数组中。使用保留操作码的指令实例（§ 6.2 ）或本规范中未记录的任何操作码不得出现在代码数组中。

Only instances of the instructions documented in §6.5 may appear in the code array. Instances of instructions using the reserved opcodes (§6.2) or any opcodes not documented in this specification must not appear in the code array.

如果类文件版本号为51.0或更高，则 jsr 操作码或 jsr_w 操作码均不会出现在代码数组。

If the class file version number is 51.0 or above, then neither the jsr opcode or the jsr_w opcode may appear in the code array.

第一段与此问题无关，因为这些指令在§6.5中列出，并未根据§6.2保留。但是第二段显然标志着它们在51.0及更高版本中被禁止。另一方面， ret 操作码在没有 jsr 或 jsr_w 的情况下是无用的，因为只有这两个指令才能创建类型为<的堆栈元素code> returnAddress （通过 astore 该类型的局部变量）由 ret 使用。

The first paragraph is irrelevant for this question, since the instructions are listed in §6.5, and are not reserved according to §6.2. But the second paragraph explicitely marks them as forbidden in version 51.0 and up. The ret opcode, on the other hand, is useless without jsr or jsr_w, since only these two instructions can create a stack element of type returnAddress (and via some astore a local variable of that type) to by used by ret.

我仍然认为应该在§6.5中包含一些这方面的通知。遗憾的是， Java错误报告网页会隐藏继续按钮，如果选择类型： Bug ，类别： Java平台标准版，子类别：规范。它声明

I still think that some notice to this effect should have been included in §6.5. Unfortunately, the Java bug report webpage hides the Continue button if one selects Type: Bug, Category: Java Platform Standard Edition, Subcategory: specification. It states that

此子类别用于报告Java语言规范和JVM规范文本中的技术错误和含糊之处。它不是在Java语言或JVM中提出新功能的场所。正在进行的功能开发在 OpenJDK 中进行;通过 Java Community Process 管理Java语言规范和JVM规范的相应增强。

This subcategory is for reporting technical errors and ambiguities in the text of the Java Language Specification and the JVM Specification. It is not the venue to propose new features in the Java language or JVM. Ongoing feature development is carried out in OpenJDK; corresponding enhancements to the Java Language Specification and the JVM Specification are managed through the Java Community Process.

但是通过JCP只是为了得到一些澄清的注释添加到这三个操作码的描述感觉就像是大量的矫枉过正。所以我希望这篇文章可以帮助那些自己无法在规范中找到答案的人。

But going through the JCP just to get some clarifying notes added to the descriptions of these three opcodes feels like massive overkill. So I hope that this post here helps those who on their own fail to find an answer in the specification itself.

这篇关于JVM规范中JSR / RET的状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！