Community
Participate
Working Groups
3.2 VM: IBM 1.5.0 SR3 - In a *large* self-hosting workspace, - Run the target eclipse - Hit a breakpoint - select a variable - it takes several seconds (sometimes 5-10 secs) to show the value, meanwhile the heap status indicator in the host eclipse goes crazy, creating 100s of meg of garbage I took a trace in YourKit of the host, and it shows one call to JavaDetailFormattersManager.getJavaProject fanning out to ~27000 calls to JarPackageFragmentRoot.initPackageFragToTypes and ~24000 calls to PackageFragmentRoot.getClassFile.
Created attachment 50737 [details] HTML export of YourKit CPU profile (with invocation counts).
My class path may be different than the norm. I have a custom PDE target pointing to a separate Eclipse 3.2 install which has a Links folder with entries pointing to EMF and GEF installs. That is, under eclipse/links there are two files emf.link with path=c:/.../emf-2.2 gef.link with path=c:/.../gef-3.2-sdk
Philippe: in order to perform a 'toString()' evaluation for a selected variable, we look up its associated source element to resolve a project in which to perform the compilation for the evaluation. It sounds like this is case with a large number of projects that causes the Java model to open many package fragment roots. Have there been any changes in the way fragments are opened in 3.3? FYI, the code we use to find a source file in each root is as follows: IPackageFragment fragment = fRoot.getPackageFragment(packageName); if (fragment.exists()) { switch (fragment.getKind()) { case IPackageFragmentRoot.K_BINARY: IClassFile file = fragment.getClassFile(typeName + ".class"); //$NON-NLS-1$ if (file.exists()) { return new Object[]{file}; } break; case IPackageFragmentRoot.K_SOURCE: String[] extensions = JavaCore.getJavaLikeExtensions(); for (int i = 0; i < extensions.length; i++) { String ext = extensions[i]; ICompilationUnit unit = fragment.getCompilationUnit(typeName + '.' + ext); if (unit.exists()) { return new Object[]{unit}; } } break; } }
*** This bug has been marked as a duplicate of bug 148965 ***