Community
Participate
Working Groups
Build Identifier: 20090621-0832 I've changed default association for rt.jar for my JRE from %JDK_HOME%\src.zip file to %JDK_HOME%\full-source\j2se folder. This full source distribution had been obtained from Sun. Now when refreshing my workspace ( hitting F5 of menu item ), in a Progress view I see a long list of blocking tasks, each of which says "Refreshing external folders" (Blocked: The user operation is waiting for refresh to complete) Refreshing /.org.eclipse.jdt.core.external.folders/.link0 Further investigation shows that a '.project' file is created in "WORKSPACE\.metadata\.plugins\org.eclipse.jdt.core\.org.eclipse.jdt.core.external.folders" directory and that silent project file has a resource link to %JDK_HOME%\full-source\j2se folder. The .project file is attached as well as a snapshot of a progress screen Reproducible: Always Steps to Reproduce: 1. Obtain java full source distribution. In my case 'jdk-6u18-ea-src-b05-jrl-18_nov_2009.jar' 2. Run self-extracting jar and copy 'j2se'it under %JDK_HOME%/full-source. 3. Window->Preferences->Java->Installed JREs->EDIT 4. rt.jar->SOURCE ATTACHMENT 5. EXTERNAL FOLDER->Change to a directory containing java full source distribution. 6. Refresh workspace. BUG ( takes really long time ) To verify the culprit. 5a. EXTERNAL FILE->Change to %JDK_HOME%/src.zip. This is DEFAULT when you configure new JRE. 6a. Refresh workspace. Happens instantaneously.
Created attachment 158605 [details] "Invisible" project file
Created attachment 158607 [details] Progress view during refresh
Can not reproduce this one. I am using build I20100125-1400. Can you try one of the newer builds?
(In reply to comment #3) > Can not reproduce this one. I am using build I20100125-1400. Can you try one of > the newer builds? Occasionally I do see it's taking few seconds (3-4 seconds, perhaps) of time. But not to the level of making me think that it's hung.
(In reply to comment #4) > (In reply to comment #3) > > Can not reproduce this one. I am using build I20100125-1400. Can you try one of > > the newer builds? > > Occasionally I do see it's taking few seconds (3-4 seconds, perhaps) of time. > But not to the level of making me think that it's hung. How many projects do you have in your workspace? I have about 45.
I am able to see this behavior with my workspace where I have 30+ projects. I wouldn't be very concerned about the blocked jobs. They are just refresh jobs for each referencing project for the modified JVM. Once the blocking main refresh job is complete, these don't take much time at all. And as for the delay itself, it could be attributed to the numerous nested folders that are inside the designated source folder for rt.jar. I don't suspect anything to be wrong there. In any case, I will take a deeper look and confirm this.
One change we could do, though, is to group all projects that reference the external folder and refresh them all in one single job rather than one job for each project. What happens currently is, since the same external folder is referenced in multiple projects, the folder is refreshed once for each such project.
Created attachment 164992 [details] Proposed Patch Patch contains changes that refresh all projects referencing an external resource (that has changed) together in a single job rather than one after another. Srikanth, I believe this code was added for fixing bug 261594, which this patch changes. Do you see any problem with this approach of refreshing all projects in a single job (other than progress reporting)?
Created attachment 166028 [details] Same patch with minor changes
Released for 3.6M7.
Verified for 3.6M7 using build I20100425-2000. Note that it still takes a long time to 'Update Installed JREs' process to finish, but I now can only observe one job to refresh external folders and it does not take a long while to finish...
(In reply to comment #11) > Verified for 3.6M7 using build I20100425-2000. > > Note that it still takes a long time to 'Update Installed JREs' process to > finish, but I now can only observe one job to refresh external folders and it > does not take a long while to finish... Thinking a little more about this, I'm not really sure I should have set this bug to VERIFIED, but rather reopen it... :-S In fact, reading the summary, it's clear that the initial issue is still not fixed as that still takes a long time to Update the JREs... (In reply to comment #6) > I am able to see this behavior with my workspace where I have 30+ projects. I > wouldn't be very concerned about the blocked jobs. They are just refresh jobs > for each referencing project for the modified JVM. Once the blocking main > refresh job is complete, these don't take much time at all. And as for the > delay itself, it could be attributed to the numerous nested folders that are > inside the designated source folder for rt.jar. I don't suspect anything to be > wrong there. In any case, I will take a deeper look and confirm this. I disagree with that comment. I think there's something wrong here and the proposed fix still does not address it. Even if the specified folder has a huge hierarchy, maybe the Update process could be optimized. I used a 3.6 full source workspace (i.e. all plugins imported as 'Projects with source folders') and it took more than 30 minutes to update the installed JREs. May be the new source folder hierarchy is read for each updated project? Anyway, I hope we can identify a better hot spot during this process and then apply some changes which can really improve it. Sorry, but the best thing to do is currently to reopen this bug and work a little bit more on it...
Frédéric, Please try to get some yourkit data using your test case. Thanks.
(In reply to comment #13) > Frédéric, > > Please try to get some yourkit data using your test case. > Thanks. Yourkit confirms my assumption, the external source folder is refreshed for each project. The hot spot is the local refresh done in ExternalFoldersManager.createLinkFolder(IPath, boolean, IProgressMonitor) which lasts around 10s on my machine. As I had 187 projects in my Eclipse full source workspace, that exactly gives the observed 30+ minutes!
Darin, I had a look at the stack and see that the starting point is in LaunchingPlugin.VMChanges.rebind(IProgressMonitor, IJavaProject[]). There's a loop on given projects (all in the workspacein this case) which is calling the JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor) project per project (through the JREContainerInitializer). I wonder if it would be feasible to call the setClasspathOperation only once given the list of concerned projects with the corresponding list of containers? This would not be enough to fix entirely the problem but without this call given the entire projects array in one shot, there's nothing JDT/Core can do to try to avoid the unnecessary multiple refresh of the new external source folder... On JDT/Core side, if we were called with the entire list of projects, then we would need to change the algorithm of the SetContainerOperation.executeOperation to perform only one update of the external folders (called in the classpathChange(ClasspathChange)) in a such peculiar case...
Created attachment 166228 [details] Naive patch for JDT/Debug Darin, Here's a naive patch illustrating the JDT/Core need to have a chance to optimize this kind of operation. What do you think of it?
(In reply to comment #16) > Created an attachment (id=166228) [details] > Naive patch for JDT/Debug > Darin, > Here's a naive patch illustrating the JDT/Core need to have a chance to > optimize this kind of operation. What do you think of it? Looks reasonable. Please file a bug against JDT debug and we can take a closer look.
(In reply to comment #17) > > Looks reasonable. Please file a bug against JDT debug and we can take a closer > look. Opened bug 310789 and attached the patch to that bug...
Created attachment 166307 [details] Proposed patch This patch, using the previously attached JDT/Debug patch, refreshes only once the external folder of the SetContainerOperation. With this patch + JDT/Debug one, the 'Update installed JREs' process only lasts 30 secondes in my Eclipse full source workspace instead of the 30+ minutes!
(In reply to comment #19) > Created an attachment (id=166307) [details] > Proposed patch > Olivier, please review, thanks
+1.
(In reply to comment #19) > Created an attachment (id=166307) [details] > Proposed patch > Released for 3.6RC1 in HEAD stream.
With I20100513-1500, I still see multiple refreshing jobs and I could not notice any improvement compared to M7.
(In reply to comment #23) > With I20100513-1500, I still see multiple refreshing jobs and I could not > notice any improvement compared to M7. I don't understand as I do notice the improvement. Note that I cannot see any 'Refresh external folders' job blocked (see attached image in comment 2), neither using M7 nor RC1!? What was your scenario to verify this bug? The process you have to look for is: 'System: Update Installed JREs'. It should lasts a long time using M7 but should be finished in a reasonable time using RC1...
(In reply to comment #24) I could see lot of peformance improvement in the process 'System: Update Installed JREs'. With RC1 it happens instantly, whereas it takes considerable amount of time in M7. I am seeing multi 'Refresh external folders' jobs when I select many projects while pressing F5. However, normal F5 in the workspace is much faster compared to M6. Hence opened another bug 313153 to track that.
Verified for 3.6RC1 using build I20100513-1500
Verified.
*** Bug 309220 has been marked as a duplicate of this bug. ***
