java - HotSpot 堆栈防护页。红色/黄色区域及其背后的原因

Question

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 保护页？

Answer 1

在 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 可能会将其自己的数据放在红色区域之外的堆栈中)。