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.
Jeremy
On Mon, Jun 22, 2015 at 11:46 PM, Mario Torre <
neugens.limasoftw...@gmail.com> wrote:
> 2015-06-23 6:58 GMT+02:00 Jeremy Manson <jeremyman...@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/
>
