Low-Overhead Heap Profiling

[Jeremy Manson]

I haven't tried!  Another problem with our submitting things is that we
can't really test on anything other than Linux.

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.

As I said, I think we'd have to change that to jvmtiStackInfo.  Would folks
like to see some proposed JVMTI interfaces for this?

Jeremy

On Tue, Jun 23, 2015 at 6:14 AM, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> > 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150623/9cf89687/attachment.html>