Bugzilla – Full Text Bug Listing
| Summary: | [plan] Performance issues with the Export-Package "uses" directive | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Thomas Watson <tjwatson> | ||||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P4 | CC: | barthel, d.nachev, david_williams, ekke, give.a.damus, gunnar, jacek.pospychala, jens.muehlenhoff, martin.skorsky, pascal, simon_kaegi, slewis, slubicki, stefan.roeck, wtracey | ||||||
| Version: | 3.4 | Keywords: | plan | ||||||
| Target Milestone: | Mars | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 275572 | ||||||||
| Attachments: |
|
||||||||
|
Description
Thomas Watson
(In reply to comment #0) > 3) Consider adding a monitor thread that can timeout the resolve operation and > force it to take the best combination found so far. > A variant of this would be a way to specify a time bound on the resolver computation. The resolver could periodically check whether it has exceeded the time bound and take the best available solution once the time bound had been exceeded. The time bound could either be a fixed amount of time (e.g. 30 sec) or some function of the number of bundles in the algorithm (e.g. f(N,T)=N*T when N is the number of bundles and T is the specified time bound factor. If N=1000 and T=30ms then f(N,T)=30 sec). (In reply to comment #1) Thanks BJ, yes that is a better approach to implementing a timeout and should be the approach taken if we decide to implement a timeout. Created attachment 88173 [details]
patch
Patch that implements a timeout. The formula used is
min(B + (N*30), M)
Where B is the base timeout (set to 30000 ms), N is the number of bundles and M is the ceiling timeout allowed (set to 90000 ms).
I opened a separate bug 217094 to release the resolver timeout. I want to use this bug to track ideas of how to actually solve this problem in a performant way. I opened bug 217317 to consider adding an option to disable uses class space consistency checks. I also released additional tracing code to help debug the uses consistency code. Has there been any progress on this issue? AFAIK p2 uses SAT solver technology, too. One problem with the time-out is that it could lead to undeterministic behaviour, especially in scenarios with some hundrets of bundles. Stefan, on the biggest configuration I have seen (more than 2000 bundles in the final solution) the time spent in the solver has always been minimal and I have never seen it timing out. what takes the most time in p2 is the creation of the input to the solver. Wrt to the use-clause the challenge is now to map the construct to a boolean formula. Pascal, we have a target platform of 200 bundles. A lot of them are from Spring Bundle repository which heavily use "uses"-declarations. The startup time is sth above 1 minute with the default "uses"-resolver. In this case, always a package-uses-conflict is displayed (however, the conrete error varies). However, if I use -Dosgi.resolver.usesMode=ignore, startup time is below 5 seconds and no package-uses-conflict is displayed (of course). Though this is no prove, i suppose that the time-out leads to the indeterministic behaviour. What do you think? (In reply to comment #8) > Pascal, we have a target platform of 200 bundles. A lot of them are from Spring > Bundle repository which heavily use "uses"-declarations. > The startup time is sth above 1 minute with the default "uses"-resolver. In > this case, always a package-uses-conflict is displayed (however, the conrete > error varies). > > However, if I use -Dosgi.resolver.usesMode=ignore, startup time is below 5 > seconds and no package-uses-conflict is displayed (of course). Though this is > no prove, i suppose that the time-out leads to the indeterministic behaviour. > What do you think? > Yes this would indicate that we are hitting a timeout trying to find a good solution. It is also possible that there is no perfect solution to your bundle set. Unfortunately we have not made any more progress in solving this issue this release. As pascal says, more investigation is needed to uses construct onto a boolean formula. Then we need to get the smallest possible implementation of a pseudo boolean solver into the framework. It would really help if you could attach the bundle manifests of the 200 bundles involved. If you do not want to attach them here perhaps you could send me the manifests. Created attachment 128528 [details]
Bundle manifest files
Thomas, I attached a subset of the involved bundle manifests. Using them, the startup time is about half minute with standard "uses" resolving and less than 5 seconds with osgi.resolver.usesMode=ignore.
With every other bundle added to the configuration the startup time extends, even if these bundles have explicit dependencies to others (Require-Bundle) and no "uses-"-constraints in their export packages.
I suppose that the webservice libraries cause the bad performance because leaving them out increases startup time clearly.
I hope this helps. Let me know if you need further information.
Stefan, in comment #7 I was talking about the p2 resolver (SAT-based solver) and not about the current OSGi the solver. This is where the confusion is coming from. Is this old plan item now fixed? (With resolver work done in Mars?) (In reply to David Williams from comment #12) > Is this old plan item now fixed? (With resolver work done in Mars?) Yes, I think we should close this as addressed in Mars and any future issues should be tracked in a new bug. This bug report was mainly discussing improvements to the old implementation of the resolver which is not used anymore in Equinox so any new issues will have to be addressed in a different way and should be done in a different bug. |