Fix performance issue and infinite loop in classpath computation#2204
Fix performance issue and infinite loop in classpath computation#2204vogella wants to merge 1 commit intoeclipse-pde:masterfrom
Conversation
|
Please add meaningful title and descriptions see https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#using-draft-pull-requests before opening draft PRs. |
vogella
changed the title
vogella
force-pushed
the
classpath-computation
branch
4 times, most recently
from
d023d5c to
6bc9ca3
Compare
vogella
force-pushed
the
classpath-computation
branch
from
6bc9ca3 to
6bf6825
Compare
vogella
force-pushed
the
classpath-computation
branch
4 times, most recently
from
6790616 to
f170c65
Compare
| } | ||
|
|
||
| Map<BundleDescription, List<Rule>> map = retrieveVisiblePackagesFromState(desc); | ||
| Map<BundleDescription, Set<Rule>> map = retrieveVisiblePackagesFromState(desc); |
There was a problem hiding this comment.
As order is important we should use a SequencedSet as generic here to make it clear also at all other places...
There was a problem hiding this comment.
The actual classes used in the details is LinkedHashSet. Other places use Set.of() will be problematic.
There was a problem hiding this comment.
Set.of() remains anywhere in the relevant context, every map value is now a new LinkedHashSet<>(). The current state is consistent and the compiler agrees with it (clean build verified earlier).
vogella
force-pushed
the
classpath-computation
branch
from
f170c65 to
834c24b
Compare
| if (junitBundle.getVersion().compareTo(JUNIT_5_9) < 0) { | ||
| // JUnit 5.8 and below bundles don't have specific version requirements that we can use | ||
| junitRequirements = collectRequirements( | ||
| JUNIT5_RUNTIME_PLUGINS.stream().map(id -> PluginRegistry.findModel(id, BELOW_JUNIT_5_9))); |
There was a problem hiding this comment.
JUNIT5_RUNTIME_PLUGINS is unstable set, stream of it is unstable too, and at line 618 we iterate over for (BundleDescription desc : junitRequirements)
There was a problem hiding this comment.
Not a bug introduced here, but should be fixed
|
By the way I'm not sure if order in general matters for these rules, and maybe JDT even do not care at all in wich case we can simply use a |
vogella
force-pushed
the
classpath-computation
branch
3 times, most recently
from
bdbd6fa to
21a81c3
Compare
vogella
force-pushed
the
classpath-computation
branch
from
21a81c3 to
ab78bea
Compare
Optimize access rule accumulation in RequiredPluginsClasspathContainer by using Set<Rule> instead of List<Rule> to avoid O(N) containment checks during insertion, which was causing O(N^2) complexity for plug-ins with many re-exported packages. Add a recursion guard in findExportedPackages to prevent infinite loops when processing cyclic re-exports in implicit or secondary dependencies. Add two tests: - RequiredPluginsClasspathContainerPerformanceTest: verifies that classpath computation finishes quickly even when secondary dependencies form a cyclic re-export graph. - ChainedReexportPerformanceTest: verifies performance in a chained re-export scenario to ensure no O(N^2) scaling. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
vogella
force-pushed
the
classpath-computation
branch
from
ab78bea to
d943a80
Compare
4 participants
Optimize access rule accumulation by using Set instead of List to avoid O(N) containment checks during insertion, which was causing O(N^2) complexity for plug-ins with many re-exported packages.
Additionally, add a recursion guard in findExportedPackages to prevent infinite loops when processing cyclic re-exports in implicit or secondary dependencies.