Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 337272

Summary:

GroupingChecker.populateRoots() can take a very long time

Product:

[Eclipse Project] Equinox

Reporter:

Kevan Miller <kevan.miller>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

glyn.normington, jgawor

Version:

3.6

Target Milestone:

3.7 M6

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Bug Depends on:

Bug Blocks:

337371

Attachments:

Description	Flags
3.6.2+ patch	none
3.6.2+ patch	none
3.7 patch	none
3.7 patch	none

Description Kevan Miller

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

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

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

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

2011-02-16 16:06:30 EST

Created attachment 189129 [details]
3.7 patch

Updated patch that applies to HEAD.

Comment 5 Thomas Watson

2011-02-16 16:44:40 EST

Patch released to HEAD.  I will open another bug to consider releasing to 3.6.2+