Low-Overhead Heap Profiling

[Jeremy Manson]

If it is a blocker for this work, we can find a way to test on OS X and
Windows.

Jeremy

On Tue, Jun 23, 2015 at 9:14 AM, Jeremy Manson <jeremymanson at google.com>
wrote:

> 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/003402b3/attachment.html>