时间戳

首页 > 解决方案 > HotSpot 堆栈保护页面。红色/黄色区域及其背后的原因

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

问题描述

Java 线程堆栈组织由下图的注释中描述。所以 1 glibc 保护页似乎是由pthread_attr_init(pthread_attr*).

我可以想象红色/黄色区域背后的原因是处理堆栈溢出而不接收SIGSEGV. 此外，此处的红色区域绝对意味着与System V AMD64 ABI中指定的内容不同，后者设置为以下 128 字节rsp，旨在保持不受中断/信号处理程序的影响。

HotSpot红色区域由-XX:StackRedPages选项控制，据我尝试，它可能是0页面3大小。

我还发现，当原始线程创建一个执行初始化步骤的线程时，它将保护大小设置pthread为 0。

问：什么是红色/黄色区域，为什么创建执行初始化的线程没有pthread保护页面？

标签： javajvmjvm-hotspot

解决方案

在 Linux 上，red 和 yellow_reserved 区域的一种（可能是其他一些）用法是让 JVM HotSpot 处理堆栈溢出。pthreads_attr_setguardsize手册页有一个关于将保护大小设置为 0 的注释：

处理堆栈溢出是应用程序的责任（可能通过mprotect(2)在已分配的堆栈末尾手动定义保护区）。

和

将保护大小设置为 0 可能有助于在创建许多线程并知道永远不会发生堆栈溢出的应用程序中节省内存。

因此，由于没有线程（甚至是原始线程）在其堆栈中使用映射，此时MAP_GROWSDOWN将保护大小设置为 0可能被视为一种优化。// JVM在函数中手动映射的页面保证了“永远不会发生stackoverflow” 。reservedyellowredvoid JavaThread::create_stack_guard_pages()

pthread可以看出，即使没有' 保护页面，线程堆栈底部的某些部分也被视为HotSpot Guard Pages，按照手册页告诉我们的方式受到权利保护。mprotect

堆栈溢出的实际处理是通过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保留或黄色区域上未保护保护页面时引发 ，则将StackOverflowError错误分派到 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可能会将其在红色区域之外的堆栈上拥有自己的数据）。

推荐阅读