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

AsyncGetCallTrace 源码深度剖析原创

2年前
822816

前言

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 线程处于安全点而被阻塞,从而导致此时无法执行该方法而获取线程栈的场景,或者在执行过程中线程被有关安全点挂起而导致获取线程栈失败这两个场景发生。

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

参考

请先登录,再评论

源码上如何看出是异步的呢,还是只能通过信号来实现异步?

9月前

为你推荐

不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
字符串字面量长度是有限制的
前言 偶然在一次单元测试中写了一个非常长的字符串字面量。 正文 在一次单元测试中,我写了一个很长的字符串字面量,大概10万个字符左右,编译时,编译器给出了异常告警 `java: constant
多次字符串相加一定要用StringBuilder而不用-吗?
今天在写一个读取Java class File并进行分析的Demo时,偶然发现了下面这个场景(基于oracle jdk 1.8.0_144): ``` package test; public c
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm
JDK13 GA发布:5大特性解读
JDK13 GA版本 5大新特性如下: 350: Dynamic CDS Archives 351: ZGC: Uncommit Unused Memory 353: Reimplement the
译:谁是 JDK8 中最快的 GC
我们都知道 OpenJDK8 有好几个垃圾回收算法,比如 ParallelGC,CMS,还有 G1,那么哪个才是最快的?如果 GC 算法从 Java8 中默认的 ParallelGC 切换到 G1 会
Javassist实现JDK动态代理
提到JDK动态代理,相信很多人并不陌生。然而,对于动态代理的实现原理,以及如何编码实现动态代理功能,可能知道的人就比较少了。接下一来,我们就一起来看看JDK动态代理的基本原理,以及如何通过Javass