Java 线程堆栈组织由以下描述 diagram in comments .所以 1 glibc guard page 似乎是由 pthread_attr_init(pthread_attr*)
设置的默认值。
我可以想象在红色/黄色区域背后的原因是在没有接收到 SIGSEGV
的情况下处理堆栈溢出。此外,这里的红色区域肯定与 System V AMD64 ABI 中指定的内容不同。它被设置为低于 rsp
的 128 字节,旨在保持中断/信号处理程序不受影响。
HotSpot 红色区域由 -XX:StackRedPages
选项控制,据我所知,它可能是 0
到 3
中的页面大小。
我还发现当原始线程创建一个执行初始化步骤的线程时 sets the pthread
guard size to 0 .
问:什么是红色/黄色区域?为什么执行初始化的线程创建时没有pthread
保护页?
最佳答案
在 Linux 上,red 和 yellow_reserved 区域的一种(可能是其他一些)用法是让 JVM HotSpot 处理堆栈溢出。 pthreads_attr_setguardsize
手册页有关于将守卫大小设置为 0 的注释:
it is the application's responsibility to handle stack overflow (perhaps by using
mprotect(2)
to manually define a guard area at the end of the stack that it has allocated).
和
Setting a guard size of 0 may be useful to save memory in an application that creates many threads and knows that stack overflow can never occur.
因此,由于没有线程(即使是原始线程)使用 MAP_GROWSDOWN
在这个 point 处为他们的堆栈映射将守卫大小设置为 0可能可以被视为优化。 reserved
保证“stackoverflow 永远不会发生”/yellow
/red
JVM 在函数 void JavaThread::create_stack_guard_pages()
中手动映射的页面.
可以看出,线程堆栈底部的某些部分即使没有 pthread
的保护页被视为 HotSpot Guard Pages那是guarded与 mprotect
正如手册页告诉我们的那样。
堆栈溢出的实际处理是通过signal handler完成的在 JVM 启动时安装。栈溢出相关的部分是这个(有点长):
// Handle ALL stack overflow variations here
if (sig == SIGSEGV) {
address addr = (address) info->si_addr;
// check if fault address is within thread stack
if (thread->on_local_stack(addr)) {
// stack overflow
if (thread->in_stack_yellow_reserved_zone(addr)) {
if (thread->thread_state() == _thread_in_Java) {
if (thread->in_stack_reserved_zone(addr)) {
frame fr;
if (os::Linux::get_frame_at_stack_banging_point(thread, uc, &fr)) {
assert(fr.is_java_frame(), "Must be a Java frame");
frame activation =
SharedRuntime::look_for_reserved_stack_annotated_method(thread, fr);
if (activation.sp() != NULL) {
thread->disable_stack_reserved_zone();
if (activation.is_interpreted_frame()) {
thread->set_reserved_stack_activation((address)(
activation.fp() + frame::interpreter_frame_initial_sp_offset));
} else {
thread->set_reserved_stack_activation((address)activation.unextended_sp());
}
return 1;
}
}
}
// Throw a stack overflow exception. Guard pages will be reenabled
// while unwinding the stack.
thread->disable_stack_yellow_reserved_zone();
stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::STACK_OVERFLOW);
} else {
// Thread was in the vm or native code. Return and try to finish.
thread->disable_stack_yellow_reserved_zone();
return 1;
}
} else if (thread->in_stack_red_zone(addr)) {
// Fatal red zone violation. Disable the guard pages and fall through
// to handle_unexpected_exception way down below.
thread->disable_stack_red_zone();
tty->print_raw_cr("An irrecoverable stack overflow has occurred.");
// This is a likely cause, but hard to verify. Let's just print
// it as a hint.
tty->print_raw_cr("Please check if any of your loaded .so files has "
"enabled executable stack (see man page execstack(8))");
} else {
//...
从代码中可以看出。如果SIGSEGV
当在保留区或黄色区域上保护页面不 protected 时引发,StackOverflowError
错误被分派(dispatch)到 Java 中,并在堆栈展开时重新启用守卫。
相比之下,如果 SIGSEGV
在红色区域被视为“不可恢复的堆栈溢出错误”时引发。
例如:
public class Main {
static void foo() throws Exception {
foo();
}
public static void main(String args[]) throws Exception {
foo();
}
}
可以通过 gdb
注意到这个StackOverflowError
发生在保留/黄色区域,而不是红色区域(所以这可能是它可以由 try
- catch
处理程序处理的原因)。
作为结论,HotSpot 守卫红色区域与 AMD64 System V ABI 具有完全不同的含义红色区域定义(只是调用者可以放置本地变量的区域,这样它们就不会被信号/中断处理程序或调试器触及,因为 gdb
可能会将其自己的数据放在红色区域之外的堆栈中)。
关于java - HotSpot 堆栈防护页。红色/黄色区域及其背后的原因,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56940808/