Low-Overhead Heap Profiling

Jeremy Manson jeremymanson at google.com
Tue Jun 23 07:39:54 UTC 2015

Mario and Kirk -

Random followup to the comments:

Mario: Internally, we have both a callback mechanism (which is off by
default) and a sampling mechanism, which is always on.  We can certainly
contribute both.  The callback mechanism has a strict rule that you don't
call JNI in it.  The one thing you can do is register to throw an OOME
after you return from the allocation - some folks wanted to use this to
rate limit how much allocation a given request could do.

Kirk: We have had a bug open for a long time for an extension that says how
many GC cycles a given sample survived.  That might be useful, and would
actually be pretty easy to implement.

I don't want to do to much work on this (or, more likely, tell one of the
folks on my team to do it) until we have a way forward to get this
interface into some JDK distribution at some point.


On Mon, Jun 22, 2015 at 11:46 PM, Mario Torre <
neugens.limasoftware at gmail.com> wrote:

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

More information about the serviceability-dev mailing list