Bugzilla – Full Text Bug Listing
| Summary: | Galileo builds the workspace very slow | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | bierwirt |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Olivier_Thomann |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
| Attachments: | |||
|
Description
bierwirt
Created attachment 151839 [details]
Eclipse Config
Created attachment 151840 [details]
My not-so-big error log
I suppose the error in the log occur because of the eclipse restart after uninstalling all my user-plugins, but who knows...
Could you please provide thread dumps while you are waiting for the build to complete? Created attachment 151923 [details]
Thread Dump file
As requested by Olivier Thomann. This thread dump is created by jstack, I hope it fits the requirements.
Today I tried to earlier releases, namlely R-3.5-200906111540 and R-3.4.2-200902111700 vanilla-style with fresh installations from http://download.eclipse.org/eclipse/downloads/ I had the same problem in Release 3.5 but not in 3.4.2 (which was my previous version). I hope this info helps. I'll turn for now back to 3.4.2 because I can't have such a long workspace build while executing an ant webbuild-reload. This is some important information about the bug:
After some confirmations from my collegues which use the same setup, it turned out that the problem disappears when we remove (or rename) the {workspace}/.metadata directory.
after that the problem disappears. It seems that old preferences or something prevented Galileo to fulfill its work properly. I suppose the bug report should stay open, because it has still relevance, hasn't it?
Does the problem come back once the workspace is restarted ? I see nothing obvious from the thread dumps. "Worker-7" and "Worker-0" seem to be in a deadlock, but this is nothing related to JDT. John, any idea ? (In reply to comment #7) > Does the problem come back once the workspace is restarted ? > I see nothing obvious from the thread dumps. > "Worker-7" and "Worker-0" seem to be in a deadlock, but this is nothing related > to JDT. > John, any idea ? Worker-7 and Worker-0 are just idle worker threads waiting for more jobs to be added to the queue. All of this looks normal to me, nothing is locked and the compile is proceeding. Does the project have any other builders on it, such as API tools builder? If you provide your .project file we could check. Also, there are some debug options that would print more details about where the time is going in the build: org.eclipse.core.resources/debug=true org.eclipse.core.resources/build/invoking=true (add to file called .options as sibling of eclipse executable and launch with -debug command line argument) Created attachment 152926 [details]
debug output with .options file and command line option -debug
As requested I created a file .options with the mentioned values. the thread dump file follows in the next attachment
Created attachment 152927 [details]
thread dump file from a run with .options and -debug
The thread dump from a run with .options and -debug
Thanks for the attachments. This shows that the time is really being spent in the Java builder, as opposed to some other builder or a listener. Are you using APT ? Could you please add the following lines to the .options file ? org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/builder=true org.eclipse.jdt.core/debug/builder/stats=true org.eclipse.jdt.core/debug/compiler=true And let me know what you get in the trace. Thanks. (In reply to comment #12) > Are you using APT ? when refering to the Annotation Processing Tool (not my ubuntu package manager), the answer is no. I guess the build time would then be equally as long as with the different .metadata directory (as I wrote before, there must screw up something in my .metadata directory), wouldn't it be? Anyways you people are definitely more into matters than I am ;) (In reply to comment #14) > when refering to the Annotation Processing Tool (not my ubuntu package > manager), the answer is no. I guess the build time would then be equally as > long as with the different .metadata directory (as I wrote before, there must > screw up something in my .metadata directory), wouldn't it be? Anyways you > people are definitely more into matters than I am ;) Did you try on a different machine ? I am trying to understand why can be slower in your case. (In reply to comment #15) > (In reply to comment #14) > > when refering to the Annotation Processing Tool (not my ubuntu package > > manager), the answer is no. I guess the build time would then be equally as > > long as with the different .metadata directory (as I wrote before, there must > > screw up something in my .metadata directory), wouldn't it be? Anyways you > > people are definitely more into matters than I am ;) > Did you try on a different machine ? I am trying to understand why can be > slower in your case. Actually, a co-worker of mine had _exactly_ the same problem on somewhat different hardware, including the mentioned workaround. While I have Kubuntu 8.04 on a Dell Latitude notebook, my colleague has Ubuntu 9.10 on a Dell XPS notebook. Anyways we shared the very same set of software: Eclipse Distribution, Subclipse Plugin, BEA JRockIt JRE for Ant usage. In terms of the debug.out with even more options in the .options file, I apologize that you have to wait until Tuesday, 2nd December because I am out of office. I hope this brings more light into the case. Created attachment 153479 [details]
Debug informatin while Eclipse is running
I attached the debug output while eclipse was running given the latest given options. Two more files are about to be uploaded
Created attachment 153480 [details]
Thread dump file while eclipse was building
I added the thread dump file while eclipse was building. I mention that because after the building-workspace-information disappeared, my hard disk was really busy due to eclipse.
Created attachment 153481 [details]
A Thread Dump file after my eclipse stopped saying it would build
I added the thread dump file while eclipse _after_ building. I mention that because after the building-workspace-information disappeared, my hard disk was really busy due to eclipse.
Could you try the next 3.6M4 build to see if the problem still exists in 3.6 stream ? Right now I have no idea what could cause a slow down. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |