RFR: Excluding a few default packages with StackProfiler

[Zoltan Farkas]

Hi Behrooz, 

Agree with Aleksey here,

I would like to add a few things:

Even if you are not a JDK dev, you should not exclude Jdk stack frames, not only that you will add extra bias to your results, but you will also miss optimization opportunities… (a lot of time you can write a faster Jdk equivalent class, method…)
To be honest with you I would love to see even the native stack… but that is slightly more complicated to implement, but possible (http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html <http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html> )

I recommend that you should capture as much data as possible and use filtering when you do the analysis of the data(with a UI as possible)

the way I do this is with my own “StackProfiler” (www.spf4j.org <http://www.spf4j.org/> ) which I integrated with JMH.
The profiler saves the profile data to “ssdump files” which I analyze with spf4j-ui.
In the UI I can easily filter anything that I am not interested in or I can’t do anything about it… 
The visualization I use in the UI is based on Brendan Gregg’s flame charts (previous URL)

You can also use this approach with java flight recorder (http://docs.oracle.com/javacomponents/jmc.htm <http://docs.oracle.com/javacomponents/jmc.htm> ) as well, and analyze the files with java mission control…
all you need something like this: https://code.google.com/p/spf4j/source/browse/trunk/spf4j-jmh/src/main/java/org/spf4j/stackmonitor/JmhFlightRecorderProfiler.java <https://code.google.com/p/spf4j/source/browse/trunk/spf4j-jmh/src/main/java/org/spf4j/stackmonitor/JmhFlightRecorderProfiler.java>

cheers

—Z


> On Jan 23, 2015, at 4:50 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Hi Behrooz,
> 
> On 01/23/2015 12:37 PM, Behrooz Nobakht wrote:
>> During benchmarking and playing with StackProfile,
>> I really needed to be able to exclude certain default
>> JVM packages from the stacks.
> 
> I understand the use case. However, quite some people use JMH to
> identify problems with the JDK itself. So, this new behavior should be
> turned off by default.
> 
> I also think the filtering by stack head biases the profile a lot. Think
> about e.g. the user method that calls into HashMap. It seems odd to
> filter out that stack ending in HashMap.get() -- it would miss the
> "legitimate" part of a stack. If anything, it should probably filter the
> excluded classes from the stack top, but still record it the rest of the
> stack as legitimate.
> 
>> The result is attached as a patch. I hope that it can be
>> reviewed and applied as it may be useful for others, too.
> 
> In order for us to accept your contribution, you need to sign the OCA,
> as required by OpenJDK contribution policy:
> http://openjdk.java.net/contribute/
> 
> Thanks,
> -Aleksey.
>