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

Bug 323319

Summary: [planner] Non greedy handling in the slicer brings in complete repositories
Product: [Eclipse Project] Equinox Reporter: Pascal Rapicault <pascal>
Component: p2Assignee: Pascal Rapicault <pascal>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: irbull, leberre
Version: 3.6   
Target Milestone: 3.6.1   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Bug Depends on: 323322    
Bug Blocks:    
Attachments:
Description Flags
Change to the slicer none

Description Pascal Rapicault CLA 2010-08-21 21:39:39 EDT 
When in 3.6 we changed the handling of greed, the code in the slicer got changed such that the non greedy requirements would be followed and gathered in a special variable (but not added to the slice). Unfortunately when requirements like those present in the tooling.osgi.default are processed, they cause pretty much all the IUs to be added to this special variable. 
Even though this may not be causing us a memory problems in the immediate term (because all the IUs are always loaded in memory by the repository manager), this is still causes some garbage to be created and slightly slows down the overall process (in addition of being a time bomb if we ever make repository loading smarter).

My suggestion is to change the slicer such that the set of non greedy IUs is gathered on a second pass over the result of the initial slicing.
Comment 1 Pascal Rapicault CLA 2010-08-21 21:43:48 EDT 
Created attachment 177172 [details]
Change to the slicer
Comment 2 Pascal Rapicault CLA 2010-08-21 21:45:03 EDT 
Marking this for 3.6.1 so we don't loose track of it.
Comment 3 Daniel Le Berre CLA 2010-08-22 12:52:22 EDT 
I discussed the issue with Pascal and checked the patch: this is indeed the way we should have implemented the collection of non greedy requirements in the first place, in a post processing step.
Comment 4 Pascal Rapicault CLA 2010-08-22 19:14:39 EDT 
Fixed in HEAD and 3.6.x
Comment 5 DJ Houghton CLA 2010-09-16 12:13:58 EDT 
There was a problem with tagging HEAD so this fix won't appear in integration builds until the first build after 3.7 M2.