> 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
