<div dir="ltr"><div class="gmail_extra">While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle.  Any volunteers?</div><div class="gmail_extra"><br></div><div class="gmail_extra">It will also need a little polish to be available to the world.  Open design questions for upstreaming are things like:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Should the interval between samples be configurable?</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.</div><div class="gmail_extra"><br></div>- Other than stack trace, what kind of information should the sampled data contain?  Right now, the structure is:<br><br>struct StackTraceData {<br>  ASGCT_CallTrace *trace;<br>  jint byte_size;<br>  jlong thread_id;<br>  const jbyte *name;<br>  jint name_length;<br>  jlong uid;<br>};<div class="gmail_extra"><br></div><div class="gmail_extra">(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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jeremy</div></div>