Low-Overhead Heap Profiling

[Mario Torre]

2015-06-23 6:58 GMT+02:00 Jeremy Manson <jeremymanson at google.com>:
> 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?

Yeah, this would be nice.

> - 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 safe point) , so it might be somewhat confusing to the user.

Yes, a perhaps optional callbacks would be nice too. I don't think the
"no JNI here" is a problem given the scope of the tool, although I can
see how it could be a bit confusing or kind of limiting in some cases,
but probably the benefit outweighs this issue. I can see, for example,
how a callback here could provide a plug for things like system tap
probes etc...

> - 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.

I don't think you need multiple callbacks, since the callback would be
user code, users can call additional callbacks themselves, but it also
depends on how this user code is installed. For instance, if the
outside world interface is some kind of JVMTi interface, then we
probably need to support multiple callbacks (as in multiple agents
installing their custom code). I suspect that to keep the overhead low
an higher level interface is needed to collect the allocation events,
while the callback interface mechanisms would be most useful to
implement/extend this interface, but not really meant to be used by
default.

> - 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.

It looks to me that most of the interesting stuff is here. The
questions that remain to me are how the outside interface would look
and how it would work, we can probably take a more abstracted and high
level look at it and then refine the specific step by step.

Cheers,
Mario

-- 
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:
http://endsoftpatents.org/