RFR: Excluding a few default packages with StackProfiler

[Aleksey Shipilev]

Hi Behrooz,

On 02/07/2015 11:21 PM, Behrooz Nobakht wrote:
> Thanks again for doing a review on the code. I actually share the
> same concerns that you mentioned and agree with them. I am also even
> to eventually reject this change as it might not be the best
> responsibility of JMH StackProfiler.

Hold on! I think it's still a useful feature for some cases.

> Let me just continue with two things as a follow-up discussion.
> 
> - The current patch tries to faithfully implement your last
> paragraph of how this should work. However, do you agree that this
> again will lead to the same UX issues of unbalanced stack at the
> result phase?

Not exactly what I wanted. I thought it would be sane to filter *all*
top frames with excluded classes, because the stack trace starting from
a non-excluded class is what you want.


> - Bringing a bit of context here, I used this patch on JMH to be able
>  to validate the work in https://java.net/jira/browse/JERSEY-1708 I
> wanted to be able to only focus on Jersey stack trace elements 
> regardless of my application and its container. This was the clue 
> that helped to identify the methods that are really the bottle neck
> in Jersey. If I use only the top-stack-frame-line exclusion, I still
> get a lot of stack statistics in the end either about "Sun HTTP
> server epoll" or some Jetty logic or even my own application. Still,
> I agree that was really contextual and subjective and one might not
> always be able to apply such general exclusions rules always.

I thought with proper top-stack filtering you will actually see the
stack traces ending with Jersey's stack trace elements.

Anyhow, your patch is reasonably close to final, I added a few
polishings, see:
 http://cr.openjdk.java.net/~shade/7901292/jmh-StackProfiler-2.patch

Any problems with that version? If not, I'm going to push it this week.

Thanks,
-Aleksey.