Community
Participate
Working Groups
Build 3.2RC7 Self-hosting in monster workspace (imported 1825 RAD plugins), when launching runtime workspace and placing some breakpoint (see bug 144976), the debugger is trying to find source attachment in [main] thread, which takes forever: "main" prio=6 tid=0x00034a38 nid=0x28c runnable [0x0007e000..0x0007fc44] at org.eclipse.core.internal.utils.ObjectMap.get(ObjectMap.java:133) at org.eclipse.core.internal.resources.WorkspaceRoot.getProject(WorkspaceRoot.java:160) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1575) at org.eclipse.core.internal.resources.Container.findMember(Container.java:76) at org.eclipse.core.internal.resources.Container.findMember(Container.java:67) at org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath(JavaProject.java:430) at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath(JavaProject.java:1559) at org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspath(JavaProject.java:1538) at org.eclipse.jdt.internal.core.JavaProject.getClasspathEntryFor(JavaProject.java:1448) at org.eclipse.jdt.internal.core.PackageFragmentRoot.findSourceAttachmentRecommendation(PackageFragmentRoot.java:394) at org.eclipse.jdt.internal.core.PackageFragmentRoot.getSourceAttachmentProperty(PackageFragmentRoot.java:634) at org.eclipse.jdt.internal.core.PackageFragmentRoot.getSourceAttachmentPath(PackageFragmentRoot.java:608) at org.eclipse.pde.internal.ui.launcher.WorkbenchSourcePathProvider.resolveClasspath(WorkbenchSourcePathProvider.java:113) at org.eclipse.jdt.internal.launching.RuntimeClasspathProvider.resolveClasspath(RuntimeClasspathProvider.java:60) at org.eclipse.jdt.launching.JavaRuntime.resolveSourceLookupPath(JavaRuntime.java:783) at org.eclipse.jdt.launching.sourcelookup.containers.JavaSourcePathComputer.computeSourceContainers(JavaSourcePathComputer.java:57) at org.eclipse.debug.internal.core.sourcelookup.SourcePathComputer.computeSourceContainers(SourcePathComputer.java:66) at org.eclipse.debug.core.sourcelookup.containers.DefaultSourceContainer.createSourceContainers(DefaultSourceContainer.java:112) at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.getSourceContainers(CompositeSourceContainer.java:126) - locked <0x0eaae9f8> (a org.eclipse.debug.core.sourcelookup.containers.DefaultSourceContainer) at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(CompositeSourceContainer.java:45) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupParticipant.findSourceElements(AbstractSourceLookupParticipant.java:67) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector$SourceLookupQuery.run(AbstractSourceLookupDirector.java:136) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.findSourceElements(AbstractSourceLookupDirector.java:721) at org.eclipse.jdt.internal.debug.core.JavaDebugUtils.resolveSourceElement(JavaDebugUtils.java:262) at org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink.getSourceElement(JavaStackTraceHyperlink.java:130) at org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink.linkActivated(JavaStackTraceHyperlink.java:85) at org.eclipse.ui.console.TextConsoleViewer$2.handleEvent(TextConsoleViewer.java:103) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
Had to kill workspace after more than 1 hour wait
fyi - darin, this is the issue I mentionned to you when debugging in monster workspace.
To be investigated during 3.3 M7
(In reply to comment #3) Version: 3.3.0 Build id: I20070410-1043 Test scenario: - open the monster workspace, - create a new debug launch config (running RAD product) - in the Breakpoints view, add BP's for BundleException - start the new debug session - the debugger stops at BP when a BundleException is encountered - you can navigate the stack, or the variables view --> corresponding source is not opened, --> selected variable values are not displayed --> some background process takes nearly 100% of the CPU during nearly 2 minutes I took a Yourkit snapshot, starting as soon as the debugger stops at BP. I'll attach corresponding screen shot.
Created attachment 63480 [details] Yourkit CPU snapshot
(In reply to comment #5) In the Hot spots list: org.eclipse.jdt.internal.core.JavaProject.getClasspathEntryFor(IPath) org.eclipse.jdt.internal.core.JavaProject.computeExpandedClasspath(ClasspathEntry, HashSet, ObjectVector)
Note that this is the same performance issue found in bug 148965. We are looking to address the problem in the PDE source locator (which is being circumvented in this scenario). However, this performance problem would still exist for a large workspace with pure Java projects (i.e. not plug-ins).
*** Bug 181900 has been marked as a duplicate of this bug. ***
Created attachment 63740 [details] Proposed fix
Created attachment 63741 [details] Proposed fix
Fix released for 3.3M7 in HEAD
Verified for 3.3 M7 using build I20070427-0010
*** Bug 185353 has been marked as a duplicate of this bug. ***
I am still seeing the same problem observed in bug Bug 185353. It's taking several minutes to close a long list of projects.
(In reply to comment #14) using Build id: I20070608-1718 in my 440+ projects workspace, closed 300 projects in less than 10 seconds. It sounds like fast to me.
