RFR: Excluding a few default packages with StackProfiler

[Aleksey Shipilev]

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.