Low-Overhead Heap Profiling

[Daniel D. Daugherty]

 > ASGCT_CallTrace *trace;

So it looks like this uses the AsyncGetTrace() infrastructure.
Does your tool work on Windows and MacOS X?

Dan


On 6/22/15 10:58 PM, Jeremy Manson wrote:
> While I'm glad to hear that our colleagues at RedHat would love it, it 
> will still need a sponsor from Oracle.  Any volunteers?
>
> It will also need a little polish to be available to the world.  Open 
> design questions for upstreaming are things like:
>
> - Should the interval between samples be configurable?
>
> - Should it *just* take a stack trace, or should the behavior be 
> configurable?  For example, we have a variant that allows it to invoke 
> a callback on allocation. Do you want this?  Because it is being 
> called during allocation, the callback can't invoke JNI (because of 
> the potential for a safepoint), so it might be somewhat confusing to 
> the user.
>
> - If the answer to the above is yes, should it be able to invoke 
> *multiple* callbacks with multiple intervals?  That could get very 
> expensive and hairy.
>
> - Other than stack trace, what kind of information should the sampled 
> data contain?  Right now, the structure is:
>
> struct StackTraceData {
>   ASGCT_CallTrace *trace;
>   jint byte_size;
>   jlong thread_id;
>   const jbyte *name;
>   jint name_length;
>   jlong uid;
> };
>
> (where name is the class name, and uid is just a unique identifier.) 
>  For general consumption, we'll probably have to change the 
> ASGCT_CallTrace to a jvmtiStackInfo, I suppose.
>
> Jeremy