ART异常处理机制(2) - StackOverflowError 实现

最新推荐文章于 2025-05-29 00:21:10 发布

原创

最新推荐文章于 2025-05-29 00:21:10 发布 · 置顶 · 4.4k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#ART #异常处理 #ART异常处理 #StackOverflowError

在本篇介绍 StackOverflowError 在 ART种的实现。本篇基础：ART异常处理机制(1) - SIGSEGV信号的拦截和处理

在 ART异常处理机制1 中，我们已经知道了 ART会注册信号处理函数，优先尝试处理 SIGSEGV信号。ART中总共有 4 种 handler 享有优先处理 SIGSEGV信号的权利。而StackOverflowHandler排在第二位，由于SuspendHandler是 Disable的，所以实际上第一个处理 SIGSEGV的是 StackOverflowHandler。今天我们主要分析下它的实现以及 StackOverflowError的检测和抛出。

先看下StackOverflowHandler实现的注释：

// Stack overflow fault handler.
//
// This checks that the fault address is equal to the current stack pointer
// minus the overflow region size (8K typically).  The instruction sequence
// that generates this signal is:
//
// sub r12,sp,#8192
// ldr.w r12,[r12,#0]
//
// The second instruction will fault if r12 is inside the protected region
// on the stack.
//
// If we determine this is a stack overflow we need to move the stack pointer
// to the overflow region below the protected region.

说的实际就是 stack overflow检测方法，意思是如果 sp-8k在 stack上的 protected region 空间内，那么在执行第二条指令 ldr.w r12, [r12, #0] 时，就会产生一个 SIGSEGV信号。这个8k 取决于 stack reserved page的大小，也有可能是 16k，说到这里，我们还是需要一个清晰的 java stack的布局，才能更明了的分析这个话题了。
下图是一个 ART thread的布局：

图的说明：

ART中的thread也是通过 pthread创建的，所以 pthread 开头的标注都是pthread内部的数据成员
以ART开头的标注都是 ART内部/ART thread内部的数据成员
在低地址的前两个page，都是 ---p权限，就是用来做 stack overflow检测的，分别是 pthread和ART创建的 guard page
接下来黄色部分描述的 8KB 是为了抛出 StackOverflow Exception 预留的栈空间，因为如果不预留的话，在overflow的时候，就没有栈空间用来执行抛出 StackOverflow 异常了
再下面的绿色部分，是线程真正能够使用的栈空间
最下面的部分，用来存储 pthread_internal_t 来描述当前 pthread，并有个 alignment保证下面的数据 16 byte对齐

看下一个线程 stack 在maps的情况：

7f8000d000-7f8000e000 ---p 00000000 00:00 0                              [anon:thread stack guard page]
7f8000e000-7f8000f000 ---p 00000000 00:00 0
7f8000f000-7f8010a000 rw-p 00000000 00:00 0                              [stack:7496]