Low-Overhead Heap Profiling

Jeremy Manson jeremymanson at google.com
Tue Jun 23 04:58:40 UTC 2015

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150622/e0b0e8ac/attachment.html>

More information about the serviceability-dev mailing list