This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
From the doc: Alternatively, the root method can be the entry point into the part of the Java code that you are currently interested in (for example, the doGet() method of your servlet). In both cases, only the code of this method and its callees are instrumented. I added a root method, and its appears to me that the methods that need to be profiled are not being filtered, and based on the number of methods instrumented, I believe all methods are being instrumented.
This is strange. Which profiling task are you using? Please attach the IDE log file (just the piece which prints out the profiling settings used). The Profile Entire application would instrument everything, the Part of App would instrument a transitive closure of methods that could be executed as part of execution of the root method(s). If you use custom profiling, the "Instrument spawned threads" should not be used, otherwise all Threads' run methods would be treated as roots and for most apps this would result in a large number of methods being instrumented.
Jon, please reopen when you gat a chance to provide more details.
You say not to use "Instrument spawned threads", but doesn't the UI when selecting this say "Instrument new threads STARTED WITHIN ROOT METHODS EXECUTION", so that to me indicates thats exactly what I want... These new threads should NOT be considered roots unless they were spawned from code that was a result of the methods that I indicated were my roots. Here's the settings I'm using: Profiler.modifyCurrentProfiling: name: Profile doExecute() profilingType =16 overrideGlobalSettings =false workingDir = jvmArgs: javaPlatform =<project> threadsMonitoringEnabled =true excludeWaitTime =false cpuProfilingType =0 instrScheme =1 threadCPUTimerOn =false instrumentGetterSetterMethods =true instrumentEmptyMethods =true instrumentMethodInvoke =false instrumentSpawnedThreads =true nProfiledThreadsLimit =-32 sortResultsByThreadCPUTime =false samplingInterval =10 instrumentationRootMethods =[Source Code defined via methods: 1 methods: class: com.bmc.patrol.patsdk.solutions.jmx.JmxParamlet method: doExecute (Lcom/bmc/patrol/patsdk/solution/paramlet/ParamletExecuteArguments;)V , Source Code defined via methods: 1 methods: class: com.bmc.patrol.patsdk.solutions.ping.PingParamlet method: doExecute (Lcom/bmc/patrol/patsdk/solution/paramlet/ParamletExecuteArguments;)V , Source Code defined via methods: 1 methods: class: com.bmc.patrol.patsdk.solutions.jmx.JmxDiscoveryParamlet method: doExecute (Lcom/bmc/patrol/patsdk/solution/paramlet/ParamletExecuteArguments;)V ] codeFragmentSelection =null codeRegionCPUResBufSize =1000 runGCOnGetResultsInMemoryProfiling =true allocTrackEvery =10 allocStackTraceLimit =0 selectedInstrFilter =Profile All Classes Instrumentation filter: Filter type: None Filter value:
*** Issue 71045 has been marked as a duplicate of this issue. ***
This issue pretty much negates any value of the CPU profiling mode of this product has for what I and others on my development team need.
Attaching sample code that shows the problem. This program actually seems to also surface several other problems as well with the profiler... but please ignore them for now, and if for some reason profiling fails to complete within a moment or so, stop and retry until you get a successful profile run. Then review the profile results, calls to method shouldNotBeProfiled are still profiled, even though they shouldn't due to what method was marked as root. Run program with a custom profile: "testNewThreadsWithinRoots" Profiler.connectToStartedApp: profiling settings ------------------------------- name: testNewThreadsWithinRoots profilingType =16 overrideGlobalSettings =false workingDir = jvmArgs: javaPlatform =<project> threadsMonitoringEnabled =true excludeWaitTime =true cpuProfilingType =0 instrScheme =1 threadCPUTimerOn =false instrumentGetterSetterMethods =true instrumentEmptyMethods =true instrumentMethodInvoke =true instrumentSpawnedThreads =true nProfiledThreadsLimit =-32 sortResultsByThreadCPUTime =false samplingInterval =10 instrumentationRootMethods =[Source Code defined via methods: 1 methods: class: ProfileTest method: profileRoot (Ljava/util/concurrent/ExecutorService;)V ] codeFragmentSelection =null codeRegionCPUResBufSize =1000 runGCOnGetResultsInMemoryProfiling =true allocTrackEvery =10 allocStackTraceLimit =0 selectedInstrFilter =Profile All Classes
Created attachment 29746 [details] Sample program that demonstrates profiler is not honoring "Instrument new threads started within root methods execution"
Changing the issue type. This is definitely not a defect. The UI now states "Instrument new threads started after entering any of root methods" and from the documentation "...we have added an option which makes it treat all void run() methods of all classes that extend java.lang.Thread or implement java.lang.Runnable, and are loaded by the VM after your designated root method has been started, as implicit roots. That is, the void run() method of such classes is instrumented once the class is loaded. This process, however, does not start until the root method is loaded, and works only for classes loaded after the root class is loaded. If your root method is the main method of the application, all application threads are instrumented; otherwise only the threads started after the root method invocation are instrumented." Anyway, the requirement to instrument only threads started within the call tree originated in a root method is still a good idea, thus leaving it open as a feature.
Milestone cleanup: future->next