Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 337272 - GroupingChecker.populateRoots() can take a very long time
Summary: GroupingChecker.populateRoots() can take a very long time
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.6   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.7 M6   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 337371
  Show dependency tree
 
Reported: 2011-02-15 20:52 EST by Kevan Miller CLA
Modified: 2011-02-16 16:45 EST (History)
2 users (show)

See Also:


Attachments
3.6.2+ patch (3.36 KB, patch)
2011-02-16 08:44 EST, Thomas Watson CLA
no flags Details | Diff
3.6.2+ patch (4.43 KB, patch)
2011-02-16 09:07 EST, Thomas Watson CLA
no flags Details | Diff
3.7 patch (3.40 KB, patch)
2011-02-16 09:36 EST, Thomas Watson CLA
no flags Details | Diff
3.7 patch (3.71 KB, patch)
2011-02-16 16:06 EST, Thomas Watson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevan Miller CLA 2011-02-15 20:52:49 EST
The isConsistentClassSpace checking that is triggered for bundles with DynamicImport-Package can take a *very* long time to complete. In some (admittedly poorly structured bundles), this resolution can take over 30 minutes.

Here's a snippet of the call stack while we're churning away in populateRoots():

	at org.eclipse.osgi.internal.module.ResolverExport.getUsesDirective(ResolverExport.java:45)
	at org.eclipse.osgi.internal.module.GroupingChecker$PackageRoots.isConsistentClassSpace(GroupingChecker.java:307)
	at org.eclipse.osgi.internal.module.GroupingChecker.isConsistentInternal(GroupingChecker.java:113)
	at org.eclipse.osgi.internal.module.GroupingChecker.isConsistentInternal(GroupingChecker.java:67)
	at org.eclipse.osgi.internal.module.GroupingChecker.populateRoots(GroupingChecker.java:36)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveDynamicImport(ResolverImpl.java:1569)
	- locked <0x93b1aee0> (a org.eclipse.osgi.internal.module.ResolverImpl)
	at org.eclipse.osgi.internal.resolver.StateImpl.linkDynamicImport(StateImpl.java:835)
	- locked <0x939a1cb8> (a java.lang.Object)
	at org.eclipse.osgi.internal.loader.BundleLoader.findDynamicSource(BundleLoader.java:1068)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:474)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Comment 1 Thomas Watson CLA 2011-02-16 08:44:42 EST
Created attachment 189093 [details]
3.6.2+ patch

Here is a 3.6.2+ patch.  I will attach a separate patch against HEAD for 3.7.

The issue is we re-calculate the class space (in GroupingChecker.populateRoots) for a bundle each time that bundle has a dynamic package load request.  This can be rather expensive if the bundle has lots of dependencies and is also doing lots of dynamic package imports.

This patch only calculates the full class space for a bundle once and then modifies the class space dynamically when new dynamic package wires are established.  Before we simply recalculated the whole space so there was no need to dynamically update the space.
Comment 2 Thomas Watson CLA 2011-02-16 09:07:46 EST
Created attachment 189094 [details]
3.6.2+ patch

The last patch neglected the case where dynamic imports were dynamically added by a weaver.
Comment 3 Thomas Watson CLA 2011-02-16 09:36:21 EST
Created attachment 189096 [details]
3.7 patch

3.7 patch is more simple since the dynamic import code was restructured and simplified a bit to handle the weaving hook in OSGi R4.3.
Comment 4 Thomas Watson CLA 2011-02-16 16:06:30 EST
Created attachment 189129 [details]
3.7 patch

Updated patch that applies to HEAD.
Comment 5 Thomas Watson CLA 2011-02-16 16:44:40 EST
Patch released to HEAD.  I will open another bug to consider releasing to 3.6.2+