第44篇-为native方法设置解释执行入口
2024-09-20 00:38:48
对于Java中的native方法来说，实际上调用的是C/C++实现的本地函数，由于可能会在Java解释执行过程中调用native方法，或在本地函数的实现过程中调用Java方法，所以当两者相互调用时，必须要遵守调用约定，同时要保证在被调用方法执行完成后，调用者的方法能继续向下执行。
在HotSpot VM中，Java方法调用native方法会有2个入口例程，一个为解释执行的入口例程，一个为“编译”执行的入口例程。所谓“编译”执行其实是如果一个native方法在解释模式被调用到了CompileThreshold次数之后，HotSpot VM会为该方法专门生成一个Native wrapper，将其方法属性、参数迁移之类的信息都固化进去，相比解释执行开销会小一些。Native wrapper生成好之后会保存到方法的Method::_from_compiled_entry属性中。
这一篇我们先介绍为解释执行生成的例程。
1、InterpreterGenerator::generate_native_entry()函数生成解释执行的入口例程
之前介绍过调用InterpreterGenerator::generate_normal_entry()函数生成Java方法解释执行的入口，而调用InterpreterGenerator::generate_native_entry()函数会生成native方法的入口，最终会将生成的例程入口保存到Interpreter::_entry_table一维数组中，通过MethodKind来从一维数组中获取对应方法类型的例程。
InterpreterGenerator::generate_native_entry()函数生成的例程的逻辑比较多，我们分几部分来解读。
（1）生成native方法的栈帧
下面详细介绍生成native方法栈帧的生成过程。
// 在调用此例程时，各个寄存器中的值如下：
// rbx: Method*
// r13: sender sp 0x00007fffe1014c00: mov 0x10(%rbx),%rcx // 将ConstMethod*存储到%rcx中
0x00007fffe1014c04: movzwl 0x2a(%rcx),%ecx // 将参数的大小存储到%ecx中
0x00007fffe1014c08: pop %rax // 将返回地址弹出到%rax中 // rbx: Method*
// rcx: size of parameters 通过上面的操作，将参数的大小存储到rcx寄存器中，如果是int、byte等为1个slot，而long和double为2个slot，所以这里指的是需要slot的大小
// r13: sender sp
// for natives the size of locals is zero
// compute beginning of parameters (r14) // 根据%rsp和参数大小计算参数的地址
// %r14指向栈顶第一个参数的位置
0x00007fffe1014c09: lea -0x8(%rsp,%rcx,8),%r14 // 为本地调用初始化两个8字节的数据，其中一个保存result_handler，一个保存oop temp
0x00007fffe1014c0e: pushq $0x0
// oop temp对于静态的native方法来说，保存的可能是mirror，
// 或者native方法调用结果为对象时，保存这个对象
0x00007fffe1014c13: pushq $0x0
需要注意，在InterpreterGenerator::generate_native_entry()中调用generate_fixed_frame()方法之前，会开辟2个8字节的空间，分别用来存放result_handler和oop temp，而在 InterpreterGenerator::generate_normal_entry()函数中调用时不会开辟这2个8字节的空间。
如上汇编执行完成后的栈图如下所示。
调用generate_fixed_frame()函数生成的汇编如下：
0x00007fffe1014c18: push %rax 0x00007fffe1014c19: push %rbp
0x00007fffe1014c1a: mov %rsp,%rbp 0x00007fffe1014c1d: push %r13
0x00007fffe1014c1f: pushq $0x0
0x00007fffe1014c24: mov 0x10(%rbx),%r13
0x00007fffe1014c28: lea 0x30(%r13),%r13
0x00007fffe1014c2c: push %rbx
0x00007fffe1014c2d: mov 0x18(%rbx),%rdx
0x00007fffe1014c31: test %rdx,%rdx
0x00007fffe1014c34: je 0x00007fffe1014c41
0x00007fffe1014c3a: add $0x90,%rdx
0x00007fffe1014c41: push %rdx
0x00007fffe1014c42: mov 0x10(%rbx),%rdx
0x00007fffe1014c46: mov 0x8(%rdx),%rdx
0x00007fffe1014c4a: mov 0x18(%rdx),%rdx
0x00007fffe1014c4e: push %rdx
0x00007fffe1014c4f: push %r14
0x00007fffe1014c51: pushq $0x0
0x00007fffe1014c56: pushq $0x0
0x00007fffe1014c5b: mov %rsp,(%rsp)
如上汇编代码在之前介绍“为Java方法创建新栈帧”时详细介绍过，逻辑基本类似，这里不再过多介绍。
执行完如上汇编后的栈帧状态如下：
接下来生成的汇编片段如下（可以添加虚拟机参数-XX:-UseStackBanging和-XX:-ProfileInterpreter，这样暂时不生成栈检查和统计相关的汇编代码，我们只关注最主要的逻辑）：
// 将JavaThread::do_unlock_if_synchronized变量设置为true
0x00007fffe1014c5f: movb $0x1,0x2ad(%r15)
// ... 计数等操作
// 将JavaThread::do_unlock_if_synchronized变量设置为false
0x00007fffe1014d48: movb $0x0,0x2ad(%r15) // 省略调用lock_method()函数生成的汇编代码，如果是同步方法，
// 则还会调用lock_method()函数生成相关的汇编代码 // 省略调用__ notify_method_entry()函数生成的汇编代码，
// 不会对当前栈帧的布局产生任何影响 // 从栈帧中取出Method*存储到%rbx中
0x00007fffe1014d87: mov -0x18(%rbp),%rbx
// 获取ConstMethod*存储到%r11中
0x00007fffe1014d8b: mov 0x10(%rbx),%r11
// 将方法参数的大小放到%r11d中
0x00007fffe1014d8f: movzwl 0x2a(%r11),%r11d
// 将%r11d中的内容左移3位，也就是算出方法参数需要占用的字节数
0x00007fffe1014d94: shl $0x3,%r11d
// 更新%rsp的值，为方法参数开辟存储参数的空间
0x00007fffe1014d98: sub %r11,%rsp
// 对linux系统来说不起作用
0x00007fffe1014d9b: sub $0x0,%rsp
// 必须是16字节边界（see amd64 ABI）
0x00007fffe1014d9f: and $0xfffffffffffffff0,%rsp
System V / AMD64 ABI要求16字节堆栈对齐。详细信息可以参考其它文章。
（2）连接Method::signature_handler并调用
下面继续看汇编的逻辑：
// 将Method::signature_handler存储到%r11中
0x00007fffe1014da3: mov 0x68(%rbx),%r11
// 如果Method::signature_handler非空,则跳转到L1
0x00007fffe1014da7: test %r11,%r11
0x00007fffe1014daa: jne 0x00007fffe1014e40 // 执行到这里，说明Method::signature_handler属性的值为空，
// 需要调用InterpreterRuntime::prepare_native_call()函数
// 确保native方法已经绑定且安装了方法签名解析代码
// 调用__ call_VM()函数生成如下例程
0x00007fffe1014db0: callq 0x00007fffe1014dba
0x00007fffe1014db5: jmpq 0x00007fffe1014e38
0x00007fffe1014dba: mov %rbx,%rsi
0x00007fffe1014dbd: lea 0x8(%rsp),%rax
0x00007fffe1014dc2: mov %r13,-0x38(%rbp)
0x00007fffe1014dc6: mov %r15,%rdi
0x00007fffe1014dc9: mov %rbp,0x200(%r15)
0x00007fffe1014dd0: mov %rax,0x1f0(%r15)
0x00007fffe1014dd7: test $0xf,%esp
0x00007fffe1014ddd: je 0x00007fffe1014df5
0x00007fffe1014de3: sub $0x8,%rsp
0x00007fffe1014de7: callq 0x00007ffff66af6aa
0x00007fffe1014dec: add $0x8,%rsp
0x00007fffe1014df0: jmpq 0x00007fffe1014dfa
0x00007fffe1014df5: callq 0x00007ffff66af6aa
0x00007fffe1014dfa: movabs $0x0,%r10
0x00007fffe1014e04: mov %r10,0x1f0(%r15)
0x00007fffe1014e0b: movabs $0x0,%r10
0x00007fffe1014e15: mov %r10,0x200(%r15)
0x00007fffe1014e1c: cmpq $0x0,0x8(%r15)
0x00007fffe1014e24: je 0x00007fffe1014e2f
0x00007fffe1014e2a: jmpq 0x00007fffe1000420
0x00007fffe1014e2f: mov -0x38(%rbp),%r13
0x00007fffe1014e33: mov -0x30(%rbp),%r14
0x00007fffe1014e37: retq
// 结束__ call_VM()函数的调用 // 将Method*存储到%rbx中
0x00007fffe1014e38: mov -0x18(%rbp),%rbx
// 将Method::signature_handler放到%11中
0x00007fffe1014e3c: mov 0x68(%rbx),%r11 // **** L1 ****
// 从这里开始执行如下的代码逻辑时，Method::signature_handler已经放到了%r11中 // 调用Method::signature_handler函数
0x00007fffe1014e40: callq *%r11
// 调用signature_handler，解析方法参数，整个
// 过程一般不会改变rbx，但是慢速处理时可能导致GC，
// 所以调用完成后最好重新获取Method
0x00007fffe1014e43: mov -0x18(%rbp),%rbx
// 将%rax中的result_handler存储到方法栈帧中，result_handler
// 是执行signature_handler例程后的返回值，根据方法签名的返回类型获取的
0x00007fffe1014e47: mov %rax,0x18(%rbp)
调用的InterpreterRuntime::prepare_native_call()函数会查找native方法对应的本地函数实现并存储到Method的native_function中，同时还会创建signature_handler并存储到Method实例中。我们在《深入剖析Java虚拟机：源码剖析与实例详解（基础卷）》中介绍过Method类，如果是表示native方法的Method实例，那么在为Method实例分配内存时会多分配2个指针大小的空间，如下图所示。
关于native function和signature handler我们后面介绍。
（3）为静态的native方法准备mirror参数
回到InterpreterGenerator::generate_native_entry()函数，继续查看生成的汇编代码，如下：
// 将Method::access_flags存储到%r11d中
0x00007fffe1014e4b: mov 0x28(%rbx),%r11d
// 判断是否为static本地方法，其中$0x8表示JVM_ACC_STATIC
0x00007fffe1014e4f: test $0x8,%r11d
// 如果为0,表示是非static方法，要跳转到-- L2 --
0x00007fffe1014e56: je 0x00007fffe1014e74 // 执行这里代码时，说明方法是static方法
// 如下4个mov指令将通过Method->ConstMehod->ConstantPool->mirror
// 获取到java.lang.Class的oop
0x00007fffe1014e5c: mov 0x10(%rbx),%r11
0x00007fffe1014e60: mov 0x8(%r11),%r11
0x00007fffe1014e64: mov 0x20(%r11),%r11
0x00007fffe1014e68: mov 0x70(%r11),%r11
// 将mirror存储到栈帧中，也就是oop temp这个slot位置
0x00007fffe1014e6c: mov %r11,0x10(%rbp)
// 将mirror拷到%rsi中作为静态方法调用的第2个参数
0x00007fffe1014e70: lea 0x10(%rbp),%rsi // **** L2 ****
// 不管是静态还是非静态方法，都会执行如下的汇编片段
对于非静态方法，如上汇编不会产生任何作用，对于静态方法来说，会将静态方法所在类对应的java.lang.Class对象存储到0x10(%rbp)的位置，也就是栈帧中oop temp的位置。
（4）连接Method::native_function并调用
// 获取Method::native_function的地址并存储到%rax中
0x00007fffe1014e74: mov 0x60(%rbx),%rax
// %r11中存储的是SharedRuntime::native_method_throw_unsatisfied_link_error_entry()
0x00007fffe1014e78: movabs $0x7ffff6a08f14,%r11
// 判断rax中的地址是否是native_method_throw_unsatisfied_link_error_entry的
// 地址，如果是说明本地方法未绑定
0x00007fffe1014e82: cmp %r11,%rax
// 如果不等于，即native方法已经绑定，跳转到----L3----
0x00007fffe1014e85: jne 0x00007fffe1014f1b // 执行这里的代码，说明native方法没有绑定，
// 调用InterpreterRuntime::prepare_native_call()函数重试，完成native方法绑定
0x00007fffe1014e8b: callq 0x00007fffe1014e95
0x00007fffe1014e90: jmpq 0x00007fffe1014f13
0x00007fffe1014e95: mov %rbx,%rsi
0x00007fffe1014e98: lea 0x8(%rsp),%rax
0x00007fffe1014e9d: mov %r13,-0x38(%rbp)
0x00007fffe1014ea1: mov %r15,%rdi
0x00007fffe1014ea4: mov %rbp,0x200(%r15)
0x00007fffe1014eab: mov %rax,0x1f0(%r15)
0x00007fffe1014eb2: test $0xf,%esp
0x00007fffe1014eb8: je 0x00007fffe1014ed0
0x00007fffe1014ebe: sub $0x8,%rsp
0x00007fffe1014ec2: callq 0x00007ffff66af6aa
0x00007fffe1014ec7: add $0x8,%rsp
0x00007fffe1014ecb: jmpq 0x00007fffe1014ed5
0x00007fffe1014ed0: callq 0x00007ffff66af6aa
0x00007fffe1014ed5: movabs $0x0,%r10
0x00007fffe1014edf: mov %r10,0x1f0(%r15)
0x00007fffe1014ee6: movabs $0x0,%r10
0x00007fffe1014ef0: mov %r10,0x200(%r15)
0x00007fffe1014ef7: cmpq $0x0,0x8(%r15)
0x00007fffe1014eff: je 0x00007fffe1014f0a
0x00007fffe1014f05: jmpq 0x00007fffe1000420
0x00007fffe1014f0a: mov -0x38(%rbp),%r13
0x00007fffe1014f0e: mov -0x30(%rbp),%r14
0x00007fffe1014f12: retq
// 结束__ call_VM()函数的调用 // 重新获取Method*到%rbx中
0x00007fffe1014f13: mov -0x18(%rbp),%rbx
// 获取native_function的地址拷到%rax中
0x00007fffe1014f17: mov 0x60(%rbx),%rax // **** L3 ****
如上汇编为调用native_function本地函数准备了参数。此时的寄存器状态如下：
%rbx：Method* // 表示native方法的Method实例
%rax：native_function // 本地函数的指针
%rsi：mirro // 是静态方法调用时的第2个参数
%rdi：JavaThread::jni_environment // 是为本地方法准备的第1个参数
继续看如下汇编：
// 将当前线程的JavaThread::jni_environment放入c_rarg0，也就是%rdi中
0x00007fffe1014f1b: lea 0x210(%r15),%rdi // 将last_java_fp存储到JavaThread::JavaFrameAnchor::last_java_fp
0x00007fffe1014f22: mov %rbp,0x200(%r15)
// 将last_java_pc存储到JavaThead::JavaFrameAnchor::last_java_pc
0x00007fffe1014f29: movabs $0x7fffe1014f22,%r10
0x00007fffe1014f33: mov %r10,0x1f8(%r15)
// 将last_java_sp保存到JavaThead.JavaFrameAnchor.last_java_pc中
0x00007fffe1014f3a: mov %rsp,0x1f0(%r15) // 将线程的状态改成_thread_in_native
0x00007fffe1014f41: movl $0x4,0x288(%r15)
// 调用native_function本地函数
0x00007fffe1014f4c: callq *%rax // 方法调用结束校验或者恢复CPU控制状态
0x00007fffe1014f4e: vzeroupper
// 如下4行代码是为了保存调用native_function函数后得到的结果，将
// 结果存储到栈顶
0x00007fffe1014f51: sub $0x10,%rsp
0x00007fffe1014f55: vmovsd %xmm0,(%rsp)
0x00007fffe1014f5a: sub $0x10,%rsp
0x00007fffe1014f5e: mov %rax,(%rsp)
在调用完本地函数后会执行如下汇编：
// 改变线程的状态为_thread_in_native_trans
0x00007fffe1014f62: movl $0x5,0x288(%r15) // 调用MacroAssembler::serialize_memory()函数
0x00007fffe1014f6d: mov %r15d,%r11d
0x00007fffe1014f70: shr $0x4,%r11d
0x00007fffe1014f74: and $0xffc,%r11d
0x00007fffe1014f7b: movabs $0x7ffff7ff5000,%r10
// 结束MacroAssembler::serialize_memory()函数
在执行完如上的汇编代码后，我们已经执行完了native_function指向的本地函数，同时将本地函数的返回结果也存储到了栈顶。
（5）对执行完native_function的安全点和异常的处理
继续执行如下汇编：
// check for safepoint operation in progress and/or pending suspend requests
// 判断安全点的状态是否为_not_synchronized
0x00007fffe1014f85: mov %r11d,(%r10,%r11,1)
0x00007fffe1014f89: cmpl $0x0,0x1639454d(%rip) # 0x00007ffff73a94e0
// 如果不相等，则处于安全点，跳转到---- L ----
0x00007fffe1014f93: jne 0x00007fffe1014fa7 // 判断当前线程的suspend_flags是否为0，如果
// 是0则跳转到---- Continue ----，表示没有未处理的异常
0x00007fffe1014f99: cmpl $0x0,0x30(%r15)
0x00007fffe1014fa1: je 0x00007fffe1014fbd // **** L ****
// 执行这里汇编时，说明处于安全点并且有未处理的异常 // 将JavaThread存储到c_rarg0中
0x00007fffe1014fa7: mov %r15,%rdi
// 临时将%rsp存储到%r12中
0x00007fffe1014faa: mov %rsp,%r12
// linux下不起作用
0x00007fffe1014fad: sub $0x0,%rsp
// 栈按16字节对齐
0x00007fffe1014fb1: and $0xfffffffffffffff0,%rsp
// 调用JavaThread::check_special_condition_for_native_trans()函数
0x00007fffe1014fb5: callq 0x00007ffff6aaf360
// 恢复%rsp
0x00007fffe1014fba: mov %r12,%rsp // **** Continue ****
继续执行如下汇编：
// 线程状态调整为_thread_in_Java，表示running in Java or in stub code
0x00007fffe1014fbd: movl $0x8,0x288(%r15) // 如下汇编清空JavaThead::JavaFrameAnchor::last_java_fp、last_java_sp与last_java_pc
0x00007fffe1014fc8: movabs $0x0,%r10
0x00007fffe1014fd2: mov %r10,0x1f0(%r15)
0x00007fffe1014fd9: movabs $0x0,%r10
0x00007fffe1014fe3: mov %r10,0x200(%r15)
0x00007fffe1014fea: movabs $0x0,%r10
0x00007fffe1014ff4: mov %r10,0x1f8(%r15) // 将JavaThread::active_handles（类型为JNIHandleBlock）存储到%r11中
0x00007fffe1014ffb: mov 0x38(%r15),%r11
// 将JavaThread::active_handles::_top属性置为NULL
0x00007fffe1014fff: movq $0x0,0x108(%r11)
线程状态在执行本地函数时的状态为_thread_in_native，执行完成后更新为_thread_in_native_trans，最后更新为_thread_in_Java，也就表示回到了调用者Java方法，所以要清空本地函数使用的句柄，这样其实就表示已经释放掉了整个JavaThread::active_handles保存的单链接JNIHandleBlock中的所有句柄了，因为第1个JNIHandleBlock的_top属性已经为0。这样的操作会让本地函数的局部对象引用全部变为无效状态。
（6）对native_function执行的结果进行处理
继续执行如下汇编代码：
// If result is an oop unbox and store it in frame where gc will see it
// and result handler will pick it up
// 从AbstractInterpreter::_native_abi_to_tosca数组中获取对应返回类型的result_handler
0x00007fffe101500a: movabs $0x7fffe100ecdb,%r11 // 比较方法的结果处理程序result_handler是否是T_OBJECT类型的
0x00007fffe1015014: cmp 0x18(%rbp),%r11 // 如果不是则跳转到----no_oop----
0x00007fffe1015018: jne 0x00007fffe101503e
// 如果是，先把栈顶的long类型的数据，即oop地址pop出来放到rax中
0x00007fffe101501e: mov (%rsp),%rax
0x00007fffe1015022: add $0x10,%rsp
0x00007fffe1015026: test %rax,%rax // 如果为0,跳转到----store_result----
0x00007fffe1015029: je 0x00007fffe1015032
// 如果不为0,那么就表示有返回的oop，注意这里的操作，因为本地函数返回的
// 是句柄，所以要从句柄中获取到真正的oop地址
0x00007fffe101502f: mov (%rax),%rax // **** store_result **** // 将%rax中的值存储到栈的oop tmp中
0x00007fffe1015032: mov %rax,0x10(%rbp)
0x00007fffe1015036: sub $0x10,%rsp
// 重新将%rax中的oop放到栈顶
0x00007fffe101503a: mov %rax,(%rsp) // **** no_oop ****
如上汇编代码对本地函数返回的结果进行了处理，尤其是当返回oop时，需要存储到栈帧中开辟的oop temp这个slot中。
（7）判断是否发生了栈溢出
继续执行如下的汇编：
// 判断当前线程的_stack_guard_state属性是否是stack_guard_yellow_disabled，即是否发生了stack overflow
0x00007fffe101503e: cmpl $0x1,0x2b4(%r15)
// 如果不等于，即没有发生stack overflow，则跳转到-- no_reguard --
0x00007fffe1015049: jne 0x00007fffe1015109 // 如果等，即发生stack overflow，则调用reguard_yellow_pages做必要的处理
0x00007fffe101504f: mov %rsp,-0x28(%rsp)
0x00007fffe1015054: sub $0x80,%rsp
0x00007fffe101505b: mov %rax,0x78(%rsp)
0x00007fffe1015060: mov %rcx,0x70(%rsp)
0x00007fffe1015065: mov %rdx,0x68(%rsp)
0x00007fffe101506a: mov %rbx,0x60(%rsp)
0x00007fffe101506f: mov %rbp,0x50(%rsp)
0x00007fffe1015074: mov %rsi,0x48(%rsp)
0x00007fffe1015079: mov %rdi,0x40(%rsp)
0x00007fffe101507e: mov %r8,0x38(%rsp)
0x00007fffe1015083: mov %r9,0x30(%rsp)
0x00007fffe1015088: mov %r10,0x28(%rsp)
0x00007fffe101508d: mov %r11,0x20(%rsp)
0x00007fffe1015092: mov %r12,0x18(%rsp)
0x00007fffe1015097: mov %r13,0x10(%rsp)
0x00007fffe101509c: mov %r14,0x8(%rsp)
0x00007fffe10150a1: mov %r15,(%rsp)
0x00007fffe10150a5: mov %rsp,%r12
0x00007fffe10150a8: sub $0x0,%rsp
0x00007fffe10150ac: and $0xfffffffffffffff0,%rsp
0x00007fffe10150b0: callq 0x00007ffff6a0e098
0x00007fffe10150b5: mov %r12,%rsp
0x00007fffe10150b8: mov (%rsp),%r15
0x00007fffe10150bc: mov 0x8(%rsp),%r14
0x00007fffe10150c1: mov 0x10(%rsp),%r13
0x00007fffe10150c6: mov 0x18(%rsp),%r12
0x00007fffe10150cb: mov 0x20(%rsp),%r11
0x00007fffe10150d0: mov 0x28(%rsp),%r10
0x00007fffe10150d5: mov 0x30(%rsp),%r9
0x00007fffe10150da: mov 0x38(%rsp),%r8
0x00007fffe10150df: mov 0x40(%rsp),%rdi
0x00007fffe10150e4: mov 0x48(%rsp),%rsi
0x00007fffe10150e9: mov 0x50(%rsp),%rbp
0x00007fffe10150ee: mov 0x60(%rsp),%rbx
0x00007fffe10150f3: mov 0x68(%rsp),%rdx
0x00007fffe10150f8: mov 0x70(%rsp),%rcx
0x00007fffe10150fd: mov 0x78(%rsp),%rax
0x00007fffe1015102: add $0x80,%rsp // **** no_guard ****
然后继续执行如下代码：
// 重新加载Method
0x00007fffe1015109: mov -0x18(%rbp),%rbx
0x00007fffe101510d: mov 0x10(%rbx),%r13
// 获取ConstMethod::code的地址存储到%r13中
0x00007fffe1015111: lea 0x30(%r13),%r13
（8）处理异常
汇编代码如下：
// 判断当前线程的_pending_exception属性是否为空，即是否发生了异常
0x00007fffe1015115: cmpq $0x0,0x8(%r15)
// 如果不为空，即没有异常，跳转到-- L --
0x00007fffe101511d: je 0x00007fffe101521f // 当前线程的_pending_exception属性不为空，表示发生了异常
// 省略调用__ MacroAssembler::call_VM()函数生成例程来调用InterpreterRuntime::throw_pending_exception()函数
// 省略调用__ should_not_reach_here()生成的汇编 // **** L ****
（9）释放锁
汇编代码如下：
// 判断目标方法是否是SYNCHRONIZED方法，如果是则需要解锁，如果不是则跳转到----L----
0x00007fffe101521f: mov 0x28(%rbx),%r11d
0x00007fffe1015223: test $0x20,%r11d
// 不需要解锁时直接跳转即可
0x00007fffe101522a: je 0x00007fffe1015405
// 获取偏向锁BasicObjectLock的地址，存储到c_rarg1中
0x00007fffe1015230: lea -0x50(%rbp),%rsi
// 获取偏向锁的_obj属性的地址
0x00007fffe1015234: mov 0x8(%rsi),%r11
0x00007fffe1015238: test %r11,%r11
// 判断_obj属性是否为空，如果不为空即未解锁，跳转到unlock完成解锁
0x00007fffe101523b: jne 0x00007fffe101533d // 如果已解锁，说明锁的状态有问题，抛出异常
// 省略调用__ MacroAssembler::call_VM()函数生成的例程，这个例程用来调用InterpreterRuntime::throw_illegal_monitor_state_exception()函数
// 省略调用__ should_not_reach_here()生成的汇编 // 调用InterpreterMacroAssembler::unlock_object()函数
// 将bcp保存到栈帧中
0x00007fffe101533d: mov %r13,-0x38(%rbp)
// %rsi中存储的是BasicObjectLock，将BasicLock存储到%rax
0x00007fffe1015341: lea (%rsi),%rax
0x00007fffe1015344: mov 0x8(%rsi),%rcx // 将_obj存储到%rcx中
0x00007fffe1015348: movq $0x0,0x8(%rsi) // 释放_obj属性
// 将_obj的markOop存储到%rdx中
0x00007fffe1015350: mov (%rcx),%rdx
0x00007fffe1015353: and $0x7,%rdx
0x00007fffe1015357: cmp $0x5,%rdx
// 如果已经是偏向状态，则跳转
0x00007fffe101535b: je 0x00007fffe1015401 // 不为偏向状态
// 将BasicLock中的markOop存储到%rdx中
0x00007fffe1015361: mov (%rax),%rdx
0x00007fffe1015364: test %rdx,%rdx
// 如果为0,说明是锁的重入，跳转
0x00007fffe1015367: je 0x00007fffe1015401
// 原子交换回原markOop，其中的%rdx中存储的就是old markOop，而%rcx中存储的是_obj
0x00007fffe101536d: lock cmpxchg %rdx,(%rcx)
// 如果为0,说明是锁的重入，跳转
0x00007fffe1015372: je 0x00007fffe1015401
// 执行这个汇编，说明为非锁重入
0x00007fffe1015378: mov %rcx,0x8(%rsi) // restore obj // 调用call_VM()函数来调用InterpreterRuntime::monitorexit()函数
0x00007fffe101537c: callq 0x00007fffe1015386
0x00007fffe1015381: jmpq 0x00007fffe1015401
0x00007fffe1015386: lea 0x8(%rsp),%rax
0x00007fffe101538b: mov %r13,-0x38(%rbp)
0x00007fffe101538f: mov %r15,%rdi
0x00007fffe1015392: mov %rbp,0x200(%r15)
0x00007fffe1015399: mov %rax,0x1f0(%r15)
0x00007fffe10153a0: test $0xf,%esp
0x00007fffe10153a6: je 0x00007fffe10153be
0x00007fffe10153ac: sub $0x8,%rsp
0x00007fffe10153b0: callq 0x00007ffff66aaab2
0x00007fffe10153b5: add $0x8,%rsp
0x00007fffe10153b9: jmpq 0x00007fffe10153c3
0x00007fffe10153be: callq 0x00007ffff66aaab2
0x00007fffe10153c3: movabs $0x0,%r10
0x00007fffe10153cd: mov %r10,0x1f0(%r15)
0x00007fffe10153d4: movabs $0x0,%r10
0x00007fffe10153de: mov %r10,0x200(%r15)
0x00007fffe10153e5: cmpq $0x0,0x8(%r15)
0x00007fffe10153ed: je 0x00007fffe10153f8
0x00007fffe10153f3: jmpq 0x00007fffe1000420
0x00007fffe10153f8: mov -0x38(%rbp),%r13
0x00007fffe10153fc: mov -0x30(%rbp),%r14
0x00007fffe1015400: retq
// 结束call_VM()调用
// 恢复bcp
0x00007fffe1015401: mov -0x38(%rbp),%r13
// 结束unlock_object()函数 // 省略调用notify_method_exit()生成的汇编
由于锁的部分我们到目前为止还没有介绍，所以这一块我们暂时不详细介绍，后面在介绍到锁相关内容时，还会介绍这里的内容。
（10）收尾
汇编代码如下：
// restore potential result in edx:eax(表示64位数), call result handler to
// restore potential result in ST0 & handle result
// 将栈顶的代表方法调用结果的数据pop到%rax中 0x00007fffe101543c: mov (%rsp),%rax
0x00007fffe1015440: add $0x10,%rsp
0x00007fffe1015444: vmovsd (%rsp),%xmm0
0x00007fffe1015449: add $0x10,%rsp
// 获取result_handler存储到%r11中
0x00007fffe101544d: mov 0x18(%rbp),%r11
// 调用result_handler处理方法调用结果
0x00007fffe1015451: callq *%r11 // 获取sender sp，开始恢复上一个Java栈帧
0x00007fffe1015454: mov -0x8(%rbp),%r11
// 相当于指令mov %ebp,%esp和pop %ebp
0x00007fffe1015458: leaveq
// 获取return address
0x00007fffe1015459: pop %rdi
// 设置sender sp
0x00007fffe101545a: mov %r11,%rsp
// 跳转到返回地址处继续执行
0x00007fffe101545d: jmpq *%rdi
如果调用本地函数返回oop，则存储到栈帧中的oop temp处，如果返回的是其它类型，如是浮点数存储在%xmm0，整数等存储在%rax中，这也是本地函数调用约定规定的，之前已经将%xmm0和%rax压入了栈顶，现在恢复到相应的寄存器中，这样就可以调用结果处理例程result_handler进行结果的处理了，处理完成后退栈，然后跳转到返回地址处继续执行即可。
基主要的执行流程如下图所示。
2、设置解释执行的入口
在Method::link_method()函数中为方法设置对应的入口entry，对于本地方法设置native入口，对于本地同步方法设置native_synchronized入口。函数的调用栈如下：
InstanceKlass::initialize_impl() instanceKlass.cpp
InstanceKlass::link_class() instanceKlass.cpp
InstanceKlass::link_class_impl() instanceKlass.cpp
InstanceKlass::link_class_impl() instanceKlass.cpp
InstanceKlass::link_methods() instanceKlass.cpp
Method::link_method() method.cpp
InstanceKlass::initialize_impl()函数在Java方法连接时会调用，这在《深入剖析Java虚拟机：源码剖析与实例详解（基础卷）》中详细介绍过。HotSpot VM对类进行连接时会调用Method::link_method()函数为Java方法设置执行入口。Method::link_method()函数的实现如下：
// 当方法所属类连接时会调用如下函数，设置Java方法的执行入口，这样Java方法就可以
// 解释执行、编译执行和动态分派了
void Method::link_method(methodHandle h_method, TRAPS) {
// 方法入口已经设置完成，不需要重复设置
if (_i2i_entry != NULL){
return;
} // 设置解释执行的入口
address entry = Interpreter::entry_for_method(h_method);
// 将解释执行的入口保存到_i2i_entry和_from_interpreted_entry
set_interpreter_entry(entry); ...
// 设置编译执行的入口
(void) make_adapters(h_method, CHECK);
}
我们暂时不介绍编译执行的入口，只看解释执行相关内容。
方法连接主要就是做的事就是设置Method::_from_interpreted_entry属性。连接过程主要是根据方法类型，获取并保存方法对应的入口例程的地址到_i2i_entry和_from_interpreted_entry属性中。
调用的Interpreter::entry_for_method()函数的实现如下：
static address entry_for_method(methodHandle m) {
AbstractInterpreter::MethodKind mk = method_kind(m);
return entry_for_kind(mk);
}
如上函数调用的method_kind()函数的实现中，与本地方法相关的逻辑如下：
// 方法中有native关键字的就是native方法
if (m->is_native()) {
assert(!m->is_method_handle_intrinsic(), "overlapping bits here, watch out");
return m->is_synchronized() ? native_synchronized : native;
}
在entry_for_method()函数中获取MethodKind后调用entry_for_kind()函数，实现如下：
static address entry_for_kind(MethodKind k) {
assert(0 <= k && k < number_of_method_entries, "illegal kind");
return _entry_table[k];
}
在函数TemplateInterpreterGenerator::generate_all()中会初始化_entry_table数组，TemplateInterpreterGenerator::generate_all()函数在HotSpot VM启动时就会调用，所以_entry_table中保存的内容会在HotSpot VM启动时就会设置。
在Method::link_method()函数中调用的set_interpreter_entry()函数的实现如下：
void set_interpreter_entry(address entry){
_i2i_entry = entry;
_from_interpreted_entry = entry;
}
公众号 深入剖析Java虚拟机HotSpot 已经更新虚拟机源代码剖析相关文章到60+，欢迎关注，如果有任何问题，可加作者微信mazhimazh，拉你入虚拟机群交流
最新文章
- pandas基础-Python3
- 一个简单的Webservice的demo,简单模拟服务
- C#中==与Equals方法的区别
- #VSTS日志# 15/11/18 插件应用市场，RM，包管理器等
- PHP Redis
- SQL 获取查询IO信息
- 学习资源asp.net
- 新建MMS草稿保存后，再进入草稿修改收件人，退出到会话界面，会显示两条草稿
- [php] 处理图像
- linux man
- leetcode 37 Sudoku Solver java
- Qt之自定义控件（开关按钮）Qt之模拟时钟
- Java-Swing嵌入浏览器（二）
- JAVA通过url获取页面内容
- 原生JS实现字符串分割
- VS2010环境下使用VB编写串口助手
- LVS三种模式分析（超详细）
- 深入浅出低功耗蓝牙(BLE)协议栈
- Mysql drop function xxxx ERROR 1305 (42000): FUNCTION (UDF) xxxx does not exist
- windows 10 WMI Provider Host 占用CPU过高的问题
热门文章
- Hadoop整体概述
- python实现开闭操作
- [loj2245]魔法森林
- [hdu7062]A Simple Problem
- [bzoj4553]序列
- [atARC110E]Shorten ABC
- 解决：ElasticsearchException[X-Pack is not supported and Machine Learning is not available for
- 计算机系统->Hello World的一生 | 程序如何运行
- Codeforces 1236F - Alice and the Cactus（期望+分类讨论）
- Codeforces 505E - Mr. Kitayuta vs. Bamboos（二分+堆）