#12 Allow include lists via profile properties file

closed
nobody
None
5
2007-06-02
2007-05-30
Andrew Wilcox
No

JIP supports the idea of an exclusion list that names classes and packages to NOT be instrumented for profiling. However, it is sometimes easier to list what you classes/packages you want instrumented rather than what you don't want instrumented. To this end, it would be nice to have an include property that allows this.

The rule for exclude and include lists would be:

1. Apply the include list
2. Then apply the exclude list

Discussion

  • rei3ner
    rei3ner
    2007-06-01

    Logged In: YES
    user_id=1316370
    Originator: NO

    i have a similar idea:

    1. wildcards e.g. in ant-style
    org.*, org.mentorgen.MostImportantClass, org.mentorgen.MostImportantClass.toString()
    2. negation: -org.*
    3. and and or: org.* | com.* or org.* & *.finish()

    if you want to, i'll provide a patch.

     
  • Andrew Wilcox
    Andrew Wilcox
    2007-06-02

    Logged In: YES
    user_id=1345666
    Originator: YES

    Thanks for the input!

    1. The exclude list already supports org.* type of exclusion. If you have:

    exclude=org

    that will do the same thing as org.*

    Exclusion at the method level is not currently supported. I'll add a separate feature request for that. I probably won't get to that until after 1.1

    2. I like the idea of using "-" for negation. However, I think it would be more intuitive to have
    exclude=org
    include=com

    3. Wow, that would be pretty cool. The "or" functionality is already present. I.e., exclude=org,com is the same of as org.* | com.*. I'm not sure about the "and" function -- I think it could get you in trouble. For example, if you say, "I want to include org.* & *.finish(). If the class/method that calls .finish(), is implicitly excluded, the user won't see the call to .finish() in the call stack section. This could lead to some confusion. If you've ever tried to make non-trivial changes to log4j logging levels based on package name, then you probably know how confusing/frustrating this type of configuration can be. I'd like to see what other users have to say about this before I commit to doing it.

     
  • Andrew Wilcox
    Andrew Wilcox
    2007-06-02

    • status: open --> closed
     
  • Andrew Wilcox
    Andrew Wilcox
    2007-06-02

    Logged In: YES
    user_id=1345666
    Originator: YES

    Fixed in 1.1 RC1. There is now an include= profile property that works the same as the exclude property (but in reverse of course!)

     
  • rei3ner
    rei3ner
    2007-06-03

    Logged In: YES
    user_id=1316370
    Originator: NO

    Hello Andrew,

    thanks for your fast answer.
    A few comments on it:

    1. My suggestion to provide "-" for negation
    is by no means incompatible with using include and exclude.
    In fact you can reformulate
    include=foo, exclude=bar
    equivalently as
    include=foo-bar
    Nevertheless, the two notations are not equally expressive:
    try conversely to express
    include=(org.-finish),com.
    in terms of include and exclude....

    I think most people (including myself)
    would prefer include=...,exclude=... over -
    *whereever* this is possible
    Maybe it is a good idea, to provide both possibilities.

    2. You are right:
    include=a,b is the same as include=a|b (say "a or b")
    the notation "or" makes sense if also "and"
    or some other operation is provided.
    3. include=a&b is as clear as the above case:
    e.g. org. & .finish()
    let you see the finilizers in the org-package.
    4. formerly i used jmp which provides above-functionality.
    so the idea is not mine, i just found it useful. ---
    maybe i'm just used to it. ;-)

    5. If one aims fine-tuning of what is profiled and what is not,
    i think one has to distinguish also between
    org.** and org.*
    as also done by ant:
    (see the ant-manual http://ant.apache.org/manual/dirtasks.html\)
    This allows to include subpackages or not, at free will.
    6. also wildcards of the form *.finish() could be helpful.

    I hope you do not feel spammed by all those ideas.

    greetings

    ernst

     
  • Andrew Wilcox
    Andrew Wilcox
    2007-06-04

    Logged In: YES
    user_id=1345666
    Originator: YES

    Hi Ernst,

    I like the org.* and org.** notation. As you pointed out, Ant uses that, so it should be familiar to most developers. Saying just "org" is not quite as intuitive, and not nearly as expressive.

    I can see that ".method()" notation/functionality would be a nice feature to add in the future. As far as adding functionality specifically for finalizers, that would be need to be thought through. Like static initializers, finalizers aren't part of a program's flow of control so you wouldn't see them in the call stack. Maybe there would be a separate section for them? Or perhaps they would should up in the "most expensive methods" section?

    1.1rc1 was just released so I'm not planning any new development until 1.1 is finalized. But I can certainly see this stuff in a 1.1.1 or 1.1.2. If you've got a patch, we can get that put in as soon as 1.1 hits the streets.

    Andrew.