Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.1
    • Fix Version/s: not determined
    • Component/s: code
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      189
    • Status Whiteboard:
      Hide

      INCOMPLETE

      Show
      INCOMPLETE

      Description

      Under settings, I entered com.** in the first box (Start profiling from classes).

      In the second box (Do not profile classes), I entered sun.rmi., com.sun.jmx..

      When the profiler runs, classes from sun.rmi and com.sun.jmx figure prominently
      in the results.

        Activity

        Hide
        jsedlacek added a comment -

        Are you sure that classes from sun.rmi are displayed in the results? Could you
        please attach the snapshot?

        If you define instrumentation root (com.**) and instrumentation filter
        (com.sun.jmx.*) which filters out the instrumentation root, the instrumentation
        root takes precedence - otherwise the profiling wouldn't work at all. This means
        that seeing com.sun.jmx in results is perfectly OK and works as designed.

        Moreover, if the Profile new Runnables checkbox is selected, it automatically
        sets all Runnable.run() methods as instrumentation roots, so it's possible that
        some sun.rmi.**.run() methods are listed in results as well.

        However, if you can see sun.rmi classes in results when Runnables checkbox is
        not selected, it is a real problem. If we had the appropriate snapshot, we could
        investigate it further.

        Show
        jsedlacek added a comment - Are you sure that classes from sun.rmi are displayed in the results? Could you please attach the snapshot? If you define instrumentation root (com.**) and instrumentation filter (com.sun.jmx.*) which filters out the instrumentation root, the instrumentation root takes precedence - otherwise the profiling wouldn't work at all. This means that seeing com.sun.jmx in results is perfectly OK and works as designed. Moreover, if the Profile new Runnables checkbox is selected, it automatically sets all Runnable.run() methods as instrumentation roots, so it's possible that some sun.rmi.**.run() methods are listed in results as well. However, if you can see sun.rmi classes in results when Runnables checkbox is not selected, it is a real problem. If we had the appropriate snapshot, we could investigate it further.
        Hide
        mrezaei added a comment -

        Profile new Runnables is checked, so I guess it "makes sense" that sun.rmi
        appears in the result. I have to say, it really makes no sense whatsoever. I was
        trying to do something simple: look at the profile for my code (in potentially
        many threads). Instead the times shown for my code are dwarfed by the rmi stuff
        that visual vm is generating (there is absolutely no rmi or jmx code in the code
        base I'm profiling).

        If I understand you correctly, there is no way to filter out stuff. The filter
        will always get trumped by the instrumentation root.

        Should this be an enhancement request? One that says make the filters really
        filter out stuff?

        Thanks
        Moh

        Show
        mrezaei added a comment - Profile new Runnables is checked, so I guess it "makes sense" that sun.rmi appears in the result. I have to say, it really makes no sense whatsoever. I was trying to do something simple: look at the profile for my code (in potentially many threads). Instead the times shown for my code are dwarfed by the rmi stuff that visual vm is generating (there is absolutely no rmi or jmx code in the code base I'm profiling). If I understand you correctly, there is no way to filter out stuff. The filter will always get trumped by the instrumentation root. Should this be an enhancement request? One that says make the filters really filter out stuff? Thanks Moh
        Hide
        jsedlacek added a comment -

        Well, the profiler works according to the provided settings. Since
        instrumentation root is set to com.** the profiler profiles this code. Is there
        any problem setting this value to actual package/class of your code - I mean
        something like com.my.code.**? This way you will ensure that only your code will
        be profiled and you won't be bothered by other code any more.

        Moreover, you can safely unselect the Runnable checkbox, instrumentation roots
        are profiled in all threads - this way you will eliminate the additional Runnables.

        I understand that the current state could be confusing, we tried to make the
        profiling as easy as possible but there are probably some limits -
        instrumentation-based profiling simply needs some setup and not everything can
        be set automatically.

        We are already thinking about a solution - not displaying profiler results which
        are filtered out by the instrumentation filter. The code still needs to be
        profiled but won't appear in the results. If you have any other idea how the
        profiling/results presentation could be improved, we would appreciate if you
        file a RFE for us. Thanks!

        Show
        jsedlacek added a comment - Well, the profiler works according to the provided settings. Since instrumentation root is set to com.** the profiler profiles this code. Is there any problem setting this value to actual package/class of your code - I mean something like com.my.code.**? This way you will ensure that only your code will be profiled and you won't be bothered by other code any more. Moreover, you can safely unselect the Runnable checkbox, instrumentation roots are profiled in all threads - this way you will eliminate the additional Runnables. I understand that the current state could be confusing, we tried to make the profiling as easy as possible but there are probably some limits - instrumentation-based profiling simply needs some setup and not everything can be set automatically. We are already thinking about a solution - not displaying profiler results which are filtered out by the instrumentation filter. The code still needs to be profiled but won't appear in the results. If you have any other idea how the profiling/results presentation could be improved, we would appreciate if you file a RFE for us. Thanks!

          People

          • Assignee:
            visualvm-issues
            Reporter:
            mrezaei
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: