07 运行时常量池索引的 rewrite

本文主要是介绍07 运行时常量池索引的 rewrite，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

如果您看过这篇文章的话, 57 相互引用的类加载的调试, 那么还记得文章最末尾留下来的问题么 ?

细心的你, 可能会发现 code 运行时的字节码和 class 文件中的字节码有一些不一样的地方 ?

发现没得, getstatic, putstatic, invokevirtual 的操作数运行时和 class文件中是不一样的, 这是咋回事呢, 这个是这个index是在Rewriter阶段重写过的(这里的细节与本文没有关系, 暂时不展开)

那么我们今天就来看一下这个问题, 呵呵究竟是哪里重写了这些索引

以下代码, 截图基于 jdk9

测试用例

package com.hx.test04;/*** LoadRefEachOther** @author Jerry.X.He <970655147@qq.com>* @version 1.0* @date 2020-03-08 10:58*/
public class Test06LoanRefEachOther {// Test06LoanRefEachOther// refer : https://hllvm-group.iteye.com/group/topic/38847public static void main(String[] args) {System.out.println(Clazz1.x1);
//    System.out.println(Clazz2.x1);System.out.println(Clazz2.x2);}/*** Clazz1** @author Jerry.X.He <970655147@qq.com>* @version 1.0* @date 2020-03-08 10:59*/private static class Clazz1 {static int x1 = 1;int f01;int f02;int f03;int f04;int f05;static {x1 = Clazz2.x2;}}/*** Clazz2** @author Jerry.X.He <970655147@qq.com>* @version 1.0* @date 2020-03-08 11:00*/private static class Clazz2 extends Clazz1 {static int x2 = 2;int f01;int f02;int f03;int f04;int f05;static {x2 = Clazz1.x1;}}}

引用一下相关字节码信息

Test06LoanRefEachOther$Clazz1.<clinit>

Clazz1static {};Code:0: iconst_11: putstatic     #3                  // Field x1:I4: getstatic     #4                  // Field com/hx/test04/Test06LoanRefEachOther$Clazz2.x2:I7: putstatic     #3                  // Field x1:I10: return

运行时 Clazz1.<clinit>方法 code 的相关信息

(lldb) print method->code_base()
(address) $247 = 0x00000001042cc480 "\x04\xffffffb3\x02"
(lldb) print method->code_size()
(int) $248 = 11
(lldb) x 0x00000001042cc480
0x1042cc480: 04 b3 02 00 b2 03 00 b3 02 00 b1 ff 00 3c ff 08  .............<..
0x1042cc490: 10 31 00 00 00 00 00 00 40 6f 43 03 01 00 00 00  .1......@oC.....# code 拆解如下
0x1042cc480: 04: iconst_1
0x1042cc481: b3 02 00: putstatic #2 // Field x1:I
0x1042cc484: b2 03 00: getstatic #3 // Field com/hx/test04/Test06LoanRefEachOther$Clazz2.x2:I
0x1042cc487: b3 02 00: putstatic #2 // Field x1:I
0x1042cc48a: b1: return

rewriter.scan_method ?

在 rewriter.scan_method 里面打一个断点

首先是 rewrite 的步骤是在类加载的 link 阶段

我们发现当前扫描的方法 code_base 为 0x10a4cc480, 当前 code 为 0x10a4cc481

0x10a4cc480 处为 iconst_1, 断点处扫描到了 "putstatic #3"

进入 rewriter. rewrite_member_reference 方法, 我们发现原来的操作数 3, 换成了 cache_index : 2

内存中的变化情况如下

(lldb) x 0x10a4cc480
0x10a4cc480: 04 b3 00 03 b2 00 04 b3 00 03 b1 ff 00 3e ff 08  .............>..
0x10a4cc490: 10 31 00 00 00 00 00 00 40 6f 63 09 01 00 00 00  .1......@oc.....
(lldb) x 0x10a4cc480
0x10a4cc480: 04 b3 02 00 b2 00 04 b3 00 03 b1 ff 00 3e ff 08  .............>..
0x10a4cc490: 10 31 00 00 00 00 00 00 40 6f 63 09 01 00 00 00  .1......@oc.....

可以看到 0x10a4cc482 开始两个字节, 00 03 换成 00 02

可以看到两点变化, 第一个是操作数本身逻辑值发生了变化, 另外一点是存储方式由大端序变成了小端序

当这个方法的所有的字节码扫描完了之后, 就完成了 class 文件中的 code 到内存中的 code 的转变了

呵呵这个常量池索引会影响到那些字节码呢?

        case Bytecodes::_putstatic      :case Bytecodes::_putfield       : {// 省略了一部分和我们这里无关的代码// fall throughcase Bytecodes::_getstatic      : // fall throughcase Bytecodes::_getfield       : // fall throughcase Bytecodes::_invokevirtual  : // fall throughcase Bytecodes::_invokestatic   :case Bytecodes::_invokeinterface:case Bytecodes::_invokehandle   : // if reverse=truerewrite_member_reference(bcp, prefix_length+1, reverse);break;

rewriter.compute_index_maps

上面还有一个问题, 转换前后的索引有什么规则呢 ? 那我们接着往下看

int  cp_entry_to_cp_cache(int i) { assert(has_cp_cache(i), "oob"); return _cp_map.at(i); }

老索引 -> 新索引是来自于这个 _cp_map

_cp_map, _cp_cache_map 的计算来自于 rewriter.compute_index_maps

前者为老索引 -> 新索引, 后者为新索引 -> 老索引

这里将 JVM_CONSTANT_InterfaceMethodref, JVM_CONSTANT_Fieldref, JVM_CONSTANT_Methodref 重新排列, 构建了索引

[add at 2021.11.21]将 JVM_CONSTANT_String, JVM_CONSTANT_MethodHandle, JVM_CONSTANT_MethodType 重新排列, 构建了索引

Test06LoanRefEachOther$Clazz1 的常量池如下

/Users/jerry/ClionProjects/HelloOpenJdk/jdk9/build/macosx-x86_64-normal-serverANDclient-slowdebug/jdk/bin/java -da -dsa -Xint -Xmx10M -XX:+UseSerialGC com.hx.test04.Test06LoanRefEachOther
Signal: SIGSEGV (signal SIGSEGV)
Signal: SIGSEGV (signal SIGSEGV)
{constant pool}- holder: 0x00000007c008fe28- cache: 0x0000000000000000- resolved_references: 0x0000000000000000- reference_map: 0x0000000000000000-   1 : Method : klass_index=5 name_and_type_index=30-   2 : Method : klass_index=6 name_and_type_index=30-   3 : Field : klass_index=5 name_and_type_index=31-   4 : Field : klass_index=32 name_and_type_index=33-   5 : Unresolved Class : 'com/hx/test04/Test06LoanRefEachOther$Clazz1'-   6 : Unresolved Class : 'java/lang/Object'-   7 : Utf8 : 'x1'-   8 : Utf8 : 'I'-   9 : Utf8 : 'f01'-  10 : Utf8 : 'f02'-  11 : Utf8 : 'f03'-  12 : Utf8 : 'f04'-  13 : Utf8 : 'f05'-  14 : Utf8 : '<init>'-  15 : Utf8 : '()V'-  16 : Utf8 : 'Code'-  17 : Utf8 : 'LineNumberTable'-  18 : Utf8 : 'LocalVariableTable'-  19 : Utf8 : 'this'-  20 : Utf8 : 'Clazz1'-  21 : Utf8 : 'InnerClasses'-  22 : Utf8 : 'Lcom/hx/test04/Test06LoanRefEachOther$Clazz1;'-  23 : Unresolved Class : 'com/hx/test04/Test06LoanRefEachOther$1'-  24 : Utf8 : '(Lcom/hx/test04/Test06LoanRefEachOther$1;)V'-  25 : Utf8 : 'x0'-  26 : Utf8 : 'Lcom/hx/test04/Test06LoanRefEachOther$1;'-  27 : Utf8 : '<clinit>'-  28 : Utf8 : 'SourceFile'-  29 : Utf8 : 'Test06LoanRefEachOther.java'-  30 : NameAndType : name_index=14 signature_index=15-  31 : NameAndType : name_index=7 signature_index=8-  32 : Unresolved Class : 'com/hx/test04/Test06LoanRefEachOther$Clazz2'-  33 : NameAndType : name_index=40 signature_index=8-  34 : Unresolved Class : 'com/hx/test04/Test06LoanRefEachOther'-  35 : Utf8 : 'com/hx/test04/Test06LoanRefEachOther$Clazz1'-  36 : Utf8 : 'java/lang/Object'-  37 : Utf8 : 'com/hx/test04/Test06LoanRefEachOther$1'-  38 : Utf8 : 'com/hx/test04/Test06LoanRefEachOther$Clazz2'-  39 : Utf8 : 'Clazz2'-  40 : Utf8 : 'x2'-  41 : Utf8 : 'com/hx/test04/Test06LoanRefEachOther'

可以发现只有两个 Field, 两个 Method, 所以图中新索引 -> 老索引的数量为 4

因为新索引从 0 开始, 索引新旧索引偏移 -1

片尾彩蛋

如果配置了 RegisterFinalizersAtInit, 那么在 Object() 的构造方法后面把 Bytecodes::_return 更新成了 Bytecodes::_return_register_finalizer

那么配置了 RegisterFinalizersAtInit 为 false 的情况, finalizer 在哪里注册呢 ?

在为对象分配空间的时候

HSDB 拿到的是 rewire 之前的字节码, 因此 RegisterFinalizersAtInit 为 true 只能在运行时验证了

(lldb) x 0x10dcc25a8
0x10dcc25a8: b1 ff 00 64 00 00 00 00 00 00 00 00 01 00 18 00  ...d............
0x10dcc25b8: 19 00 00 00 00 00 01 00 20 26 cc 0d 01 00 00 00  ........ &......
(lldb) x 0x10dcc25a8
0x10dcc25a8: e8 ff 00 64 00 00 00 00 00 00 00 00 01 00 18 00  ...d............
0x10dcc25b8: 19 00 00 00 00 00 01 00 20 26 cc 0d 01 00 00 00  ........ &......

======================= add at 2020.05.03 =======================

呵呵找到了一个之前的 todo, 链接一下

R大曾经在这篇文章中 Java 8下如何查看JVM里Java应用的字节码？介绍了常量池索引 Rewrite 的相关只是

有些字节码指令的操作数在Class文件里跟在运行时看起来不同，是因为HotSpot VM在加载类的时候会对字节码做改写，把某些指令的操作数从常量池下标（constant pool index）改写为常量池缓存下标（constant pool cache index）。这是因为这些指令所需要引用的信息比一个constant pool entry slot要大，需要另外开一个更大的数据结构来放该常量池项的内容。

完