RFR: Excluding a few default packages with StackProfiler

Behrooz Nobakht nobeh5 at gmail.com
Thu Feb 12 17:44:53 UTC 2015


Hi Alexsey,

Your patch looks very good to me. Just want to say I appreciate your
time on walking through this patch. It was quite interesting and learnt
from it.

Regards,
Behrooz


On Tue, Feb 10, 2015 at 1:38 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> 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.
>
>


-- 
-- Behrooz Nobakht


More information about the jmh-dev mailing list