Low-Overhead Heap Profiling

[Mario Torre]

I for one would love it.

Cheers,
Mario

2015-06-22 20:48 GMT+02:00 Jeremy Manson <jeremymanson at google.com>:
> Hey folks,
>
> (cc'ing Aleksey and John, because I mentioned this to them at the JVMLS last
> year, but I never followed up.)
>
> We have a patch at Google I've always wanted to contribute to OpenJDK, but I
> always figured it would be unwanted.  I've recently been thinking that might
> not be as true, though.  I thought I would ask if there is any interest / if
> I should write a JEP / if I should just forget it.
>
> The basic problem is that there is no low-overhead supported way to figure
> out where allocation hotspots are.  That is, sets of stack traces where lots
> of allocation / large allocations took place.
>
> What I had originally done (this was in ~2007) was use bytecode rewriting to
> instrument allocation sites.  The instrumentation would call a Java method,
> and the method would capture a stack trace.  To reduce overhead, there was a
> per-thread counter that only took a stack trace once every N bytes
> allocated, where N is a randomly chosen point in a probability distribution
> that centered around ~512K.
>
> This was *way* too slow, and it didn't pick up allocations through JNI, so I
> instrumented allocations at the VM level, and the overhead went away.  The
> sampling is always turned on in our internal VMs, and a user can just query
> an interface for a list of sampled stack traces.  The allocated stack traces
> are held with weak refs, so you only get live samples.
>
> The additional overhead for allocations amounts to a subtraction, and an
> occasional stack trace, which is usually a very, very small amount of our
> CPU (although I had to do some jiggering in JDK8 to fix some performance
> regressions).
>
> There really isn't another good way to do this with low overhead.  I was
> wondering how the gruop would feel about our contributing it?
>
> Thoughts?
>
> 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:
http://endsoftpatents.org/