I have been using JProfiler to analyze a piece of Java code which calls native C code via JNI, and I am getting strange results from the "CPU Views" window. In particular, the information on the "Call Tree" tab is telling me that the Java method which calls the native code consumes the highest fraction of the run time, but the "Hot Spots" tab does not even list that method at all. I also noticed a similar story for the org.joda.time classes, which are reported to have a fairly large fraction of CPU but are not reported as hot spots, and I'm wonder if this is because they spend a lot of time calling native date conversion code.
Any insight into this problem would be appreciated.
EDIT: I just discovered a very disturbing academic paper entitled "Evaluating the Accuracy of Java Profilers" (I would supply a link, but seems like the University of Colorado server referenced by the Google result for this file is very unhappy right now, so I had to pull a copy down from Google's "Quick View" link). I suspect that the problem with the native methods is that they are being over-counted because there are many calls to them, they are short and the call is likely to result in a yield point; however, I'm not sure if the same would apply to the time conversion routines. Note that I get significantly different results when using instrumented profiling and sampled profiling for the same test run, and the instrumented results agree better with my intuition. I recommend the paper to anyone who has ever found themselves scratching their heads over the results of a profiling run. Still hoping for someone to have more information on this though; "the profiler is wrong" is not a very comforting result.
EDIT 2: Looks like colorado.edu has sorted itself out, here's the link: http://www-plan.cs.colorado.edu/klipto/mytkowicz-pldi10.pdf