第44篇-为native方法设置解释执行入口

2021-12-15

对于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,拉你入虚拟机群交流