RFR: Excluding a few default packages with StackProfiler

[Behrooz Nobakht]

Hi Aleksey,

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.

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?

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

Cheers,
Behrooz


On Mon, Feb 2, 2015 at 7:38 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi Behrooz,
>
> On 01.02.2015 23:47, Behrooz Nobakht wrote:
> > Thanks for the review. Your comments actually got me thinking what I
> > do really want from this feature. This led me to somehow conclude
> > the explanation of the "exclusion". Interesting that you mentioned
> > the CSV package prefixes. I added and applied the comments. The patch
> > is attached. Please read the commit message.
>
> I have reservations about exclusionRate machinery.
>
> In addition to being a rather non-intuitive knob for a user, it can
> still deform the profiles. I think the rationale for exclusionRate stems
> from the idea that more stack frames means more time spent, but this is
> simply not true. You can frequently have (and you will have) a deep call
> chain of very small and quick methods that will invalidate that premise.
>
> Now, imagine the stack trace that has a single user code
> (non-excluded) call, that is then calls into some excluded code. You
> don't know beforehand how many stack frames would excluded code consume
> -- maybe a lot, maybe not, and so selecting proper exclusionRate becomes
> a guessing game.
>
> Or, imagine the stack trace of a big container which has lots of
> excluded stack frames, one user business logic call, then another ton of
> stack frames, then final user business logic call. Obviously, the
> exclusionRate should be very close to 1 to get the decent profile, but
> the proper margin of sane exclusionRates would also be a guessing game.
> This is not to mention the issue with the number of recorded stack lines
> you outlined.
>
> Therefore, I would like us to step back, and implement the filtering of
> the top stack frames: discard everything that matches excluded patterns
> from the top of the stack, get the remaining number of lines from the
> stack, cram them into StackRecord, done.
>
> That's what I suspect other profilers do, and this behavior would be
> less surprising for the users.
>
> Thanks,
> -Aleksey.
>
>


-- 
-- Behrooz Nobakht
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmh-StackProfiler.patch
Type: text/x-patch
Size: 11013 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jmh-dev/attachments/20150207/75785133/jmh-StackProfiler-0001.patch>