Community
Participate
Working Groups
SelectionListenerAction calls initCollections everytime selection changes and that allocates 2 arrays of size 10 everytime these arrays are mostly empty these empty arrays sum up to quite a lot of garbage after each click in the workbench
It's even worst... it calls initCollections each time the selection changes and then again when computeResources is call! Also, most of these subclasses are probably hooking themselves up to listen for selection changes at the page level. Which mean each on of these will potentially compute this collection of resources/non-resources and hold onto this copy. Even more wasted space.
We used to just clear out the arrays using clear() rather than recreating them. This was changed a while back to address a race condition bug where two threads were accessing the lists. See bug 8514 and bug 15769. Should look at lazy initializing them, and using a smaller default size. Could also consider using synchronized blocks.
The bug 8514 fixed a problem for a scenario like 1) updateSelection called 2) getResources called => clears current array and populates it 3) iterates over collection returned (using Iterator) 4) while processing one of the resources, some method call causes the selection to change 5) selectionChange is called 6) the current array is cleared => but fails because the iterator (in step 3) For M4, we will not create the arrays until they are needed (most time the non resource array contains no items). We will set the initial size of the array.
Update the code to delay as late as possible creating new arrays and also providing a reasonable initial size. Created a bug 27789 to relook at a possible better solution for this area.
Verified fixed in 20021216
