Low-Overhead Heap Profiling

Mario Torre neugens.limasoftware at gmail.com
Tue Jun 23 17:22:49 UTC 2015

2015-06-23 19:01 GMT+02:00 Jeremy Manson <jeremymanson at google.com>:
> If it is a blocker for this work, we can find a way to test on OS X and
> Windows.

Yeah, I think if this is going to be a general interface, we need to
test on all the official platforms.


> 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

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:

More information about the serviceability-dev mailing list