<div dir="ltr">If it is a blocker for this work, we can find a way to test on OS X and Windows.<div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 9:14 AM, Jeremy Manson <span dir="ltr"><<a href="mailto:jeremymanson@google.com" target="_blank">jeremymanson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I haven't tried!  Another problem with our submitting things is that we can't really test on anything other than Linux.<div><br></div><div>The reason we use ASGCT is that our modified version of ASGCT gathers native frames *and* Java frames, getting a mixed mode stack trace that crosses JNI boundaries.  I haven't checked on the details, but we could probably use a more standard stack trace gathering mechanism for general consumption.</div><div><br></div><div>As I said, I think we'd have to change that to jvmtiStackInfo.  Would folks like to see some proposed JVMTI interfaces for this?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jeremy</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 6:14 AM, Daniel D. Daugherty <span dir="ltr"><<a href="mailto:daniel.daugherty@oracle.com" target="_blank">daniel.daugherty@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> ASGCT_CallTrace *trace;<br>
<br>
So it looks like this uses the AsyncGetTrace() infrastructure.<br>
Does your tool work on Windows and MacOS X?<br>
<br>
Dan<div><div><br>
<br>
<br>
On 6/22/15 10:58 PM, Jeremy Manson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle.  Any volunteers?<br>
<br>
It will also need a little polish to be available to the world.  Open design questions for upstreaming are things like:<br>
<br>
- Should the interval between samples be configurable?<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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>
};<br>
<br>
(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.<br>
<br>
Jeremy<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>