使用-XX的安全性如何:-UseSplitVerifier？

Question

使用检测的JDK7编译代码存在已知的兼容性问题.至于http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

版本号为51的类文件使用类型检查验证程序进行独占验证,因此这些方法在适当时必须具有StackMapTable属性.对于版本为50的类文件,如果文件中的堆栈映射丢失或不正确,Hotspot JVM将(并继续)故障转移到类型推断验证程序.对于版本为51的类文件(Java SE 7的默认版本),不会发生此故障转移行为.修改版本51类文件中的字节码的任何工具必须确保更新stackmap信息以与字节码一致以通过验证.

解决方案是使用-XX:-UseSplitVerifier如下所述:https: //community.oracle.com/blogs/fabriziogiudici/2012/05/07/understanding-subtle-new-behaviours-jdk-7

它有多安全？我想Oracle已将此检查置于原因之中.如果我不使用它,我可能会冒一些其他问题.

使用后果可能是什么-XX:-UseSplitVerifier？

谢谢,

彼得.

Answer 1

简而言之,它非常安全.

从Java 6开始,Oracle的编译器使用StackMapTable创建了类文件.基本思想是编译器可以显式指定对象的类型,而不是让运行时执行它.这在运行时提供了一个微小的加速,以换取编译期间的一些额外时间和编译的类文件(前面提到的StackMapTable)中的一些复杂性.

作为实验性功能,Java 6编译器中默认情况下未启用它.如果不存在StackMapTable,则运行时默认为验证对象类型本身.

直到Java 7. Oracle强制要求:编译器生成它们,运行时验证它们.如果StackMapTable不存在,它仍然使用旧的验证程序...但仅限于Java 6或更早版本(版本50)的类文件.Java 7类文件(版本51)需要使用StackMapTable,因此运行时不会削减它们相同的松弛.

如果您的类文件是在没有StackMapTable的情况下生成的,那么这只是一个问题.例如,如果您使用的是非Oracle JVM.或者如果你之后搞乱了字节码 - 比如将其用于调试器,优化器或代码覆盖率分析器.

但你可以绕过它!Oracle的JVM提供了-XX:+ UseSplitVerifier来强制运行时回退到旧的类型验证程序.它不关心StackMapTable.

在实践中,运行速度和效率的希望优化尚未实现:如果存在,那么任何人都不会注意到它.由于新型验证器不提供任何新功能(只是优化),因此关闭它是完全安全的.

如果您搜索JSR 202,Oracle的解释请访问http://www.oracle.com/technetwork/java/javase/compatibility-417013.html.

Answer 2

是的 - 这很安全.正如Judebert所说,它只会略微减慢课堂负荷.

添加更多信息:StackMap表究竟是什么？好吧,字节码验证程序需要对类文件中的代码进行两次传递,以验证正在传递和使用的正确类型的数据.第一个传递是较慢的传递,它对所有代码的分支进行流分析,以查看每个字节码指令在堆栈上可以存在哪种类型的数据.第二遍查看每条指令,看它是否可以有效地对所有这些类型进行操作.

这是关键:编译器已经拥有第一遍生成的所有信息 - 所以(在Java 6和7中)它将它存储在类文件的StackMap表中.

这加速了类加载,因为类加载器不必执行第一次传递.这就是为什么它被称为Split Verifier,因为工作在编译器和运行时加载机制之间分开.当您使用-XX:-UseSplitVerifier选项时,您告诉Java 在类加载时执行两次传递(并忽略任何StackMap表).许多产品(如在加载时修改字节码的分析器)最初不了解StackMap表,因此当它们在加载时修改类时,编译器中的StackMap表已过时并导致错误.

总而言之,-XX:-UseSplitVerifier选项减慢了类加载速度.它不会影响安全性,运行时性能或功能.

Answer 3

堆栈映射框架在Java 7中添加,"prashant"认为该想法存在缺陷,并建议开发人员始终使用该-XX:-UseSplitVerifier标志来避免使用它们.

阅读更多:Java 7字节码验证程序:JVM的巨大后退步骤