性能文章>AsyncGetCallTrace 源码深度剖析>

AsyncGetCallTrace 源码深度剖析原创

5年前
10985611

前言

AsyncGetCallTrace 是由 OracleJDK/OpenJDK 内部提供的一个函数,该函数可以在 JVM 未进入 safepoint 时正常获取到当前线程的调用栈(换句话说,使用该函数获取线程栈时,不会要求 JVM 进入 safepoint。而进入 safepoint 对于 OpenJDK或者 OracleJDK 来说意味着会 STW 的发生,所以这意味着使用该函数获取线程栈不会产生 STW,It’s amazing.)。目前该函数仅在 Linux X86、Solaris SPARC、Solaris X86 系统下支持。
另外它还支持在 UNIX 信号处理器中被异步调用,那么我们只需注册一个 UNIX 信号处理器,并在Handler中调用 AsyncGetCallTrace 获取当前线程的调用栈即可。由于 UNIX 信号会被随机的发送给进程的某一线程进行处理,因此可以认为获取所有线程的调用栈样本是均匀的。
但是值得注意的是,该函数不是标准的 JVM API,所以使用的时候,可能存在以下问题:

  • 移植性问题,因为只能跑在 OpenJDK 或者 OracleJDK 上
  • 由于不是标准的 JVMTI API,所以使用者需要通过特殊一些方式来获取该函数,这给使用者带来了一些不便,但是这也无大碍。

源码实现

关于怎么使用该函数去进行热点方法采样的方法,不在本节的讨论范围,在参考资料中,有一些描述,如果还有不清楚的,也可以给我留言交流。

核心数据结构

// call frame copied from old .h file and renamed
//  Fields:
//    1) For Java frame (interpreted and compiled),
//       lineno    - bci of the method being executed or -1 if bci is not available
//       method_id - jmethodID of the method being executed
//    2) For native method
//       lineno    - (-3)
//       method_id - jmethodID of the method being executed
typedef struct {
    jint lineno;                      // numberline number in the source file
    jmethodID method_id;              // method executed in this frame
} ASGCT_CallFrame;

// call trace copied from old .h file and renamed
// Fields:
//   env_id     - ID of thread which executed this trace.
//   num_frames - number of frames in the trace.
//                (< 0 indicates the frame is not walkable).
//   frames     - the ASGCT_CallFrames that make up this trace. Callee followed by callers.
typedef struct {
    JNIEnv *env_id;                   // Env where trace was recorded
    jint num_frames;                  // number of frames in this trace
    ASGCT_CallFrame *frames;          // frames
} ASGCT_CallTrace;

// These name match the names reported by the forte quality kit
// 这些枚举是对应到 ASGCT_CallTrace 中的 num_frames 的返回值的
// 举个例子,当 JVM 在进行 GC 时,返回值中
// ASGCT_CallTrace.num_frames == ticks_GC_active
enum {
  ticks_no_Java_frame         =  0,
  ticks_no_class_load         = -1,
  ticks_GC_active             = -2,
  ticks_unknown_not_Java      = -3,
  ticks_not_walkable_not_Java = -4,
  ticks_unknown_Java          = -5,
  ticks_not_walkable_Java     = -6,
  ticks_unknown_state         = -7,
  ticks_thread_exit           = -8,
  ticks_deopt                 = -9,
  ticks_safepoint             = -10
};

函数申明

//   trace    - trace data structure to be filled by the VM.
//   depth    - depth of the call stack trace.
//   ucontext - ucontext_t of the LWP
void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext)

该函数的调用者获取到的栈是属于某一个特定线程的,这个线程是由 trace->env_id 唯一标识的,而且 该标识的线程 必须和当前执行 AsyncGetCallTrace 方法的 线程 是同一线程。同时调用者需要为 trace->frames 分配足够多的内存,来保存栈深最多为 depth 的栈。若获取到了有关的栈,JVM 会自动把相关的堆栈信息写入 trace 中。接下来我们通过源码来看看内部实现。

AsyncGetCallTrace 实现

具体分析直接看代码里面的注释,为了保持完整性,该方法的任何代码我都没删除,源码位置:/hotspot/src/share/vm/prims/forte.cpp

void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) {
  JavaThread* thread;
  // 1. 首先判断 jniEnv 是否为空,或者 jniEnv 对应的线程是否有效,或者该线程是否已经退出,
  // 任一条件满足,则返回 ticks_thread_exit(对应为核心数据结构中枚举类型所示)
  if (trace->env_id == NULL ||
    (thread = JavaThread::thread_from_jni_environment(trace->env_id)) == NULL ||
    thread->is_exiting()) {

    // bad env_id, thread has exited or thread is exiting
    trace->num_frames = ticks_thread_exit; // -8
    return;
  }

  if (thread->in_deopt_handler()) {

    // thread is in the deoptimization handler so return no frames
    trace->num_frames = ticks_deopt; // -9
    return;
  }

  // 2. 这里对 jniEnv 所指线程是否是当前线程进行断言,如果不相等则直接报错
  assert(JavaThread::current() == thread,
         "AsyncGetCallTrace must be called by the current interrupted thread");

  // 3. JVMTI_EVENT_CLASS_LOAD 事件必须 enable,否则直接返回 ticks_no_class_load
  if (!JvmtiExport::should_post_class_load()) {
    trace->num_frames = ticks_no_class_load; // -1
    return;
  }

  // 4. 当前 heap 必须没有进行 GC ,否则直接返回 ticks_GC_active
  if (Universe::heap()->is_gc_active()) {
    trace->num_frames = ticks_GC_active; // -2
    return;
  }

  // 5. 根据线程的当前状态来获取对应的线程栈,只有在线程的状态为 _thread_in_vm/_thread_in_vm_trans 
  // 和 _thread_in_Java/_thread_in_Java_trans 时才会进行线程栈的爬取
  switch (thread->thread_state()) {
  case _thread_new:
  case _thread_uninitialized:
  case _thread_new_trans:

    // We found the thread on the threads list above, but it is too
    // young to be useful so return that there are no Java frames.
    trace->num_frames = 0;
    break;
  case _thread_in_native:
  case _thread_in_native_trans:
  case _thread_blocked:
  case _thread_blocked_trans:
  case _thread_in_vm:
  case _thread_in_vm_trans:
    {
      frame fr;

      // 首先获取当前线程的栈顶栈帧
      // param isInJava == false - indicate we aren't in Java code
      if (!thread->pd_get_top_frame_for_signal_handler(&fr, ucontext, false)) {
        trace->num_frames = ticks_unknown_not_Java;  // -3 unknown frame
      } else {

        //  该线程如果没有任何的 Java 栈帧,直接返回 0 帧 
        if (!thread->has_last_Java_frame()) {
          trace->num_frames = 0; // No Java frames
        } else {
          trace->num_frames = ticks_not_walkable_not_Java;    // -4 non walkable frame by default

          // 如果存在合法的栈帧,则填充 trace 中的 frames 和 num_frames
          forte_fill_call_trace_given_top(thread, trace, depth, fr);
          ...
        }
      }
    }
    break;
  case _thread_in_Java:
  case _thread_in_Java_trans:
    {
      frame fr;

      // param isInJava == true - indicate we are in Java code
      if (!thread->pd_get_top_frame_for_signal_handler(&fr, ucontext, true)) {
        trace->num_frames = ticks_unknown_Java;  // -5 unknown frame
      } else {
        trace->num_frames = ticks_not_walkable_Java;  // -6, non walkable frame by default
        forte_fill_call_trace_given_top(thread, trace, depth, fr);
      }
    }
    break;
  default:

    // Unknown thread state
    trace->num_frames = ticks_unknown_state; // -7
    break;
  }
}

从以上的分析中,最终获取线程栈的地方主要在这两个方法 pd_get_top_frame_for_signal_handlerforte_fill_call_trace_given_top,接下来我们来看下这两个方法的实现。

pd_get_top_frame_for_signal_handler 实现

从方法名不难看出,该方法的主要作用是获取当前线程的栈顶帧。后面跟了个 signal_handler,最初的想法我猜应该是为响应 UNIX 下的 SIGPROF 信号的。因为本身 AsyncGetCallTrace 就是为此而生的。该方法的源码位置 /hotspot/src/os_cpu/linux_x86/vm/thread_linux_x86.cpp

bool JavaThread::pd_get_top_frame_for_signal_handler(frame* fr_addr,
  void* ucontext, bool isInJava) {

  assert(Thread::current() == this, "caller must be current thread");
  return pd_get_top_frame(fr_addr, ucontext, isInJava);
}

很简单,判断一下是否是当前线程,至于 isInJava 入参是和当前的线程的状态相关的,如果是跑在 java 代码内,则为 true,否则为 false。

pd_get_top_frame 实现

bool JavaThread::pd_get_top_frame(frame* fr_addr, void* ucontext, bool isInJava) {
  assert(this->is_Java_thread(), "must be JavaThread");
  JavaThread* jt = (JavaThread *)this;

  // If we have a last_Java_frame, then we should use it even if
  // isInJava == true.  It should be more reliable than ucontext info.
  if (jt->has_last_Java_frame() && jt->frame_anchor()->walkable()) {
    *fr_addr = jt->pd_last_frame();
    return true;
  }

  // At this point, we don't have a last_Java_frame, so
  // we try to glean some information out of the ucontext
  // if we were running Java code when SIGPROF came in.
  if (isInJava) {
    ucontext_t* uc = (ucontext_t*) ucontext;

    intptr_t* ret_fp;
    intptr_t* ret_sp;
    ExtendedPC addr = os::Linux::fetch_frame_from_ucontext(this, uc,
      &ret_sp, &ret_fp);
    if (addr.pc() == NULL || ret_sp == NULL ) {
      // ucontext wasn't useful
      return false;
    }

    frame ret_frame(ret_sp, ret_fp, addr.pc());
    if (!ret_frame.safe_for_sender(jt)) {
#ifdef COMPILER2
      // C2 uses ebp as a general register see if NULL fp helps
      frame ret_frame2(ret_sp, NULL, addr.pc());
      if (!ret_frame2.safe_for_sender(jt)) {
        // nothing else to try if the frame isn't good
        return false;
      }
      ret_frame = ret_frame2;
#else
      // nothing else to try if the frame isn't good
      return false;
#endif /* COMPILER2 */
    }
    *fr_addr = ret_frame;
    return true;
  }

  // nothing else to try
  return false;
}

实际上拿栈顶帧的函数,由于函数的源码较长,我就简短的描述一下逻辑

  • 当前线程只能是 java 线程
  • 判断栈顶帧是否存在,并且当前的栈是 walkable 的,若二者的满足,则返回 javaThread 的 pd_last_frame,即栈顶帧,结束;否则继续;
  • 如果当前线程是跑 java 代码,那么我们尝试在 ucontext_t 内收集一些我们需要的信息,比如说栈帧

forte_fill_call_trace_given_top 实现

当我们获取到栈顶的帧之后,接下来的事情就顺理成章了,只要从栈顶开始,遍历整个堆栈就能把所有的方法都获取到了,同时将获取到的结果保存到ASGCT_CallTrace,源码位置:/hotspot/src/share/vm/prims/forte.cpp

static void forte_fill_call_trace_given_top(JavaThread* thd,
                                            ASGCT_CallTrace* trace,
                                            int depth,
                                            frame top_frame) {
  NoHandleMark nhm;

  frame initial_Java_frame;
  Method* method;
  int bci = -1; // assume BCI is not available for method
                // update with correct information if available
  int count;

  count = 0;
  assert(trace->frames != NULL, "trace->frames must be non-NULL");

  // 1. 获取到栈顶的第一个 java 栈帧
  // Walk the stack starting from 'top_frame' and search for an initial Java frame.
  find_initial_Java_frame(thd, &top_frame, &initial_Java_frame, &method, &bci);

  // Check if a Java Method has been found.
  if (method == NULL) return;

  //  2. 如果不是合法的方法,直接返回
  if (!method->is_valid_method()) {
    trace->num_frames = ticks_GC_active; // -2
    return;
  }

  vframeStreamForte st(thd, initial_Java_frame, false);

  // 循环迭代栈上的所有栈帧,一一获取每个方法 bci 和 方法 id,这里会用上从外面传入的最大栈深 depth
  for (; !st.at_end() && count < depth; st.forte_next(), count++) {
    bci = st.bci();
    method = st.method();

    if (!method->is_valid_method()) {
      // we throw away everything we've gathered in this sample since
      // none of it is safe
      trace->num_frames = ticks_GC_active; // -2
      return;
    }

    // 根据方法对象获取方法 id,如果方法 id 在此时还未产生,则返回 NULL
    trace->frames[count].method_id = method->find_jmethod_id_or_null();

    // 如果方法是不是 native 方法,则把 lineno 设置为 bci 的值,否则置 -3 
    if (!method->is_native()) {
      trace->frames[count].lineno = bci;
    } else {
      trace->frames[count].lineno = -3;
    }
  }
  trace->num_frames = count;
  return;
}

总结

源码贴的有点多,这里稍微做一个小的总结,同时也说明一下使用时的一些注意事项

  • AsyncGetCallTrace 是 OpenJDK/OracleJDK 提供的可以在不暂停虚拟机的情况下可以获取线程栈的函数,开发人员的主要触发点是通过 UNIX 的 SIGPROF 信号来触发信号的 handler 来调用此函数,来随机获取某一个线程的栈,为高性能的热点方法监控提供了可行的技术支持;
  • AsyncGetCallTrace 的使用必须在 Agent onload 的时候 Enable JVMTI_EVENT_CLASS_LOAD 和 JVMTI_EVENT_CLASS_PREPARE 事件,不然无法获取相关的方法,同时还需要注册 callbacks.ClassPrepare 事件,在 class 加载准备阶段预先生成好 jMethodId,不然可能出现 jMethodId 为空的情况;
  • 实际上,AsyncGetCallTrace 还可以认为是标准 JVM-TI 中的 GetCallTrace 接口的线程安全版本。但是我们看到实际上,这个方法中所有代码都是未加锁的,为啥?细心的同学可能已经发现,因为该函数的调用是用信号处理函数调用,且只有某一个单独线程同时运行它,所以它的使用场景就天然决定了它是线程安全的。
  • 还有最后一点要注意,由于该方法的调用是在 java 线程中调用的,所以当使用者发送 SIGPROF 信号时,恰好由于进程处于 GC 阶段,而导致 java 线程处于安全点而被阻塞,从而导致此时无法执行该方法而获取线程栈的场景,或者在执行过程中线程被有关安全点挂起而导致获取线程栈失败这两个场景发生。

本文中难免存在一些错误和不足,还望大家不吝指出,同时如果对文中描述存在任何疑问,也欢迎大家提出来讨论。

参考

点赞收藏
西湖の风

Stay hungry, Stay foolish

请先登录,查看6条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

11
6