Hi Vladimir, The difference would be in the licensing.
Kind regards, Kirk Pepperdine On Jun 23, 2015, at 7:31 AM, Vladimir Voskresensky <vladimir.voskresen...@oracle.com> wrote: > Hello Jeremy, > > If this is sampling, not tracing, then how is it different from the > low-overhead memory profiling provided by JFR [1]. > JFR samples per new TLAB allocation. It provides really very good picture and > I haven't seen overhead more than 2%. > Btw, JFR also does not have false positives reported by instrumented > approaches for the cases when JIT was able to eliminate heap allocation. > > Thanks, > Vladimir. > [1] http://hirt.se/blog/?p=381 > > On 22.06.2015 11:48, Jeremy Manson wrote: >> 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 >
