JVM以编程方式获取分配调用堆栈 [英] JVM getting allocation call stacks programmatically

问题描述

这是

我确实知道，为了获取此类信息，我必须默认以1/10的速率触发采样分配，然后(最好)指定将记录分配的分类的包.

第1步

第2步

但是那时候我真的不明白如何将有关调用栈的信息匹配"到调用".以及有关已分配对象的信息.

当然，我的问题不是关于JProfiler的实现细节，我了解它是一个包含紧密代码和所有内容的商业工具，而是关于如何检索此类信息的一般理解.

我最初的猜测是，它以某种方式仪器"被识别为仪器".将已经加载的类文件拦截"到主文件.这些对象的每一次分配(使用采样率都不会太慢该过程)但是那又如何呢?它是否调用 Thread.currentThread().getStackTrace()之类的东西并记录导致分配的实际堆栈跟踪?

另一方面，在采样模式"下激活它.(与仪器相对)+性能方面的担忧-对我来说，这听起来确实是一件很昂贵的事情(阅读，不应该在生产中使用)，但是我可能错了，因此，任何建议都将不胜感激.

解决方案

我最初的猜测是，它以某种方式仪器"被识别为仪器".已经加载的类文件到拦截"指的是拦截".这些对象的每次分配

由于Java 11交付了 JEP 331 ，因此它在本机JVMTI中使用了这些功能，以便样本分配.在Java 11之前，它会检测 java.lang.Object 构造函数.至于调用堆栈，取决于是否使用检测还是采样.对于检测，它使用检测已经建立的调用堆栈.对于采样，通过采样构建的调用堆栈不够精确，因此this one

So I keep exploring modern profilers capabilities from the "programmatic access" standpoint, and I came across something beyond my understanding.

This time I've stumbled upon The "Allocation Call Tree" feature in JProfiler:

I do see that in order to get this kind of information, I have to trigger the sampled allocation with a rate of 1/10 by default and then specify (preferably) the package in which the allocated classed will be recorded.

Step 1

Step 2

But then I don't really understand how can the information about the call-stacks be "matched" with the information about the allocated objects.

Of course my question is not about the implementation details of JProfiler, I understand its a commercial tool with a close code and everything, but rather about the general understanding of how can this kind of information can be retrieved.

My initial guess is that it somehow "instruments" the already-loaded class files to "intercept" each and every allocation for these objects (with a sampling rate to not slow down the process too much) but then what? Does it call something like Thread.currentThread().getStackTrace() and records the actual stack trace that has led to the allocation?

On the other hand, its activated in the "sampling mode" (as opposed to the instrumentation) + there is a performance concern - this sounds a really expensive thing to do (read, should not be used in production) to me, but I might be wrong, so any advice will be appreciated.

解决方案

My initial guess is that it somehow "instruments" the already-loaded class files to "intercept" each and every allocation for these objects

Since Java 11 delivered JEP 331 it uses these capabilities in the native JVMTI in order to sample allocations. Before Java 11, it instruments the java.lang.Object constructor. As for the call stacks, it depends on whether instrumentation or sampling is used. For instrumentation, it uses the call stack that is already built by the instrumentation. For sampling, the call stack built by sampling is not precise enough, so it queries the call stack through JVMTI.

Does it call something like Thread.currentThread().getStackTrace()

For sampling it's a bit like that, but doing it in Java would create a huge overhead because of the many secondary allocations. JVMTI is a native interface and can do this more efficiently.

这篇关于JVM以编程方式获取分配调用堆栈的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！