Bugzilla – Full Text Bug Listing
| Summary: | Performance problem when method entry breakpoint set. | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Erin Harris <eharris> |
| Component: | Debug | Assignee: | Darin Wright <darin.eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | jared_burns |
| Version: | 2.0 | ||
| Target Milestone: | 2.0 F4 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
We know that method entry breakpoints are slow, but we do not know why jdb is not effected. There is not actually a JDI method entry breakpoint - only method entry/exit events on a per type basis which we have to translate into specific method signatures & compare. It looks like jdb creates a ClassPrepareRequest for the class (it prints out a message saying that the breakpoint will not be installed until the class is loaded) and then when the class is loaded it creates a MethodEntryRequest using the ReferenceType as the filter. Whereas it looks like JDT uses the class pattern String as the filter. Could this be the difference? Yes, this must be the difference. Looking at our code we make method entry requests with type name patterns rather than using an explicit reference type. (I thought our code used to wait until a class with the proper name/pattern was loaded - but that does not appear to be the case anymore). This would require an API change/addition. Currently the API supports method breakpoints on type name patterns (very flexibile). We would have to add an API to support method breakpoints on specific types only, to maintain API compatibility. Propose no change for 2.0. Is this critical? Could it be addressed in a fix pack (later)? The corresponding WSAD defect has been marked as beta-blocking so this is critical. I experiemented with using the "reference type" approach. I found that it was only faster because the event request was delayed (not installed) until the correpsonding type was loaded. Once the type was loaded, performance is still slow. Needs more investigation. However, why are method breakpoints used? Is there something else that could be used? (i.e. line breakpoints). The reason we are using method breakpoints is because we are setting the breakpoints in code that ships with WAS. If we were using line breakpoints and that code was changed then the breakpoints would no longer work. We could update our debug adapter but then our debug adapter would not work with older versions of WAS. We could use line breakpoints as a last resort but it is not as safe. Are the classes containing your method breakpoints loaded early in startup or later? I believe the classes are loaded after WAS initialization, when the first web object is loaded. The reference type approach makes a huge difference if the class isn't loaded immediately. I tested this using Eclipse startup. No breakpoint: 1 minute Breakpoint + old code: 8 minutes Breakpoint + new code: 1 minute Marking as F4 candidate. ARCH approval: Rather than requesting method entry/exit events for type name patterns when a VM is launched, we simulate a deferred breakpoint when a method entry request is made for a type name without wildcards. This way, the request for method entry/exit events is delayed until the type is loaded. Fix released to CVS. Please verify. Verified. |
To reproduce: 1. Create a dummy java project and add the following external jar: <WASHOME>\lib\debug.jar where WASHOME is the installation directory for WAS (such as D:\WebSphere\AppServer). 2. In the project view expand debug.jar, then expand com.ibm.debug and either the DebugBreakpoints class if it exists (this depends on which level of WAS you have installed) or DebugWebAppInvocationCollaborator. 3. Put a method entry breakpoint on the debugJSPBreakpoint method in the expanded class. 4. Create a launch configuration for a remote java application with 7777 as the port number. 5. Start the WebSphere Application Server. Make sure the server is in debug mode before you start by setting debugMode="true" in the server config file. The config file should be in <WASHOME>\config\cells\BaseApplicationServerCell\nodes\<your hostname>\servers\server1\server.xml. startserver server1 6. When you see the line "Server launched. Waiting for initialization status.", attach to the server using the launch configuration created in step 4. 7. Note how long it takes for the server to initialize (the server is initialized when you see the line "Server initialization completed. Process id is: <process id>". To see the performance difference do the same as above except do not set the method entry breakpoint. It takes about 4 times longer for the server to start when the breakpoint is set than when it is not. JDB does not show the same problem. To see this start the server as before and attach with jdb and set the breakpoint: jdb -attach 7777 suspend stop in com.ibm.debug.DebugBreakpoints.debugJSPBreakpoint OR// stop in com.ibm.debug.DebugWebAppInvocationCollaborator.debugJSPBreakpoint cont Note that jdb is just as fast when the breakpoint is set as when it is not.