Stack Profiler

[Kirk Pepperdine]

Hi Aleksey,

> 
> You should really try "-prof perfasm" with 0.9.1+ now then :)

Thanks, have done so…

The thing with prof is that it’s really amazing that this “brain dead” profiler beats all others in being consistently correct in finding meaningful bottlenecks to correct. In fact I now trust it so much that I’ll use it as a control when evaluating other profilers on different problems. I can understand the desire to pull BLOCKED or WAITING threads but IME it’s these types of problems that other profilers miss. In addition the filter sets and profiling points *often* hide the bottleneck from the end users. For example, I’ve a problem that I give my students and invariably those that use prof get the right answer where as invariably those that use any other profiler (NetBean, JProfiler… YourKit…. you name it…) get it wrong mostly because they either correct for conditions (quite often incorrectly) or no one takes care to inspect or adjust the filter sets or profiling points. The safe-point sampling behavior isn’t helpful either but that affects all profiler equally, at least those that don’t try to correct for it.

Regards,
Kirk

> 
> -Aleksey.
> 
> On 07/02/2014 09:16 PM, Kirk Pepperdine wrote:
>> Hi all,
>> 
>> May I suggest that in my studies of profilers the current implementation of StackProfiler (-prof stack) *always* provides the *best* view of where to make improvements in the code. The only thing better is oprofiler as it’s not bothered by safe points.
>> 
>> Regards,
>> Kirk
>> 
>> On Jul 2, 2014, at 6:44 PM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
>> 
>>> Hi All,
>>> 
>>> Currently StackProfiler (-prof stack) merges data from all threads and it may lead to cases when BLOCKED and/or WAITING threads stacks became dominant. I am suggesting to split stacks by different threads states.
>>> Here is a patch
>>> http://cr.openjdk.java.net/~skuksenko/jmh/stackProfiler/
>>> 
>>> -- 
>>> Best regards,
>>> Sergey Kuksenko
>> 
>