Community
Participate
Working Groups
Peter has another case of extremely long startup times using the F1 build. It appears to be very similiar to his previous case. ie. Opening with a java editor selected is slow but if you then exit with a .txt file opening the starup times get much better. Here are the steps: -> He had a similiar workspace, lots of projects with external references -> Saved workspace had Java Perspective Open, multiple files in editor area the active editor was a .java file. [His initial state was more involved but we simplified it to this] Time to startup 90 seconds -> Create a .txt file. Have it selected. Exit and restart Time to startup 23 seconds -> Close the .txt editor (which would cause the previously open java editor to become active) Time to open the java editor ~90 seconds We tried to get profile inforamation from j9 and failed. The best we could do was a stack dump of what the threads were doing and it looked like a reconciler (MonoReconciler) was running? We also tried the same case using today's build 0529 and it is still slow. Other variations: We tried making the Resource perspective active (same editors as the slow case) and it got even slower. Time to startup 184 seconds
MonoReconciler running is OK. It does so in a separate thread and should not prevent the editor from coming up. Profiling information would help to see whether the two threads *UI, MomoReconciler) block each other.
is there any way this workspace could be ftp-ed to us so that we can analyze the trace?
Yes, but it's VERY big. (~1GB including required support files). Kevin and I are going to try to profile it here, first.
Created attachment 1128 [details] Here is the stack dump
Got it. See attachment for details. The time is spent creating the outline view contents. Using the same setup as before but this time deleting the outline view the time to open the editor
added the annotation to the wrong bug... ==== I wonder whether the override indicator is the problem. Can you run the scenario again but with the override indicator turned off: Preferences>Java>Appearance: Show Override Indicator in outline and hierarchy
Changing the Show Override Indicator setting had no effect on the startup times. I also tried changing the scenario so that the Outline was open on Object at startup, since this is a much simpler class. This actually made startup even slower (>250sec).
This might be asking for a lot, but what would really help us the most is an Optimize perf trace of the start-up time. Can you produce this and export as html? Otherwise we have to do the workspace ftp-transfer. Just as a data point: our current start-up time in a self hosting workspace with one Java file is 40s (-6s from previous builds).
The trace shows that the UI thread is waiting on the JavaModelManager lock that is held by a reconciler thread. Closing the outline view makes the problem go away since then the UI thread will not request for the element info that makes it wait for the lock. The problem seems to be that the JavaModelManager lock is kept for an extended period of time. Philippe do you see a way to shorten the time that this lock is held. Moving to JDT Core for investigation.
Indeed the lock on the project element creation comprises the namelookup initialization (need to find all package fragment roots + all package fragments).
Changing the concurrency characteristics at this stage is likely asking for trouble elsewhere... need to be really careful.
David - pls gather some profiling stats using reasonable workspace (tried on a large on, and had to kill it after an hour waiting for it to show up).
The stack dump only exposes the fact that 2 identical namelookups are being created concurrently. This is causing some competion on locks. We changed the implementation so as to avoid 2 concurrent creations of the same namelookup, but the timing won't look much different, in so far as one will wait idle while the namelookup is ready to use. So the characteristics will be pretty much the same.
I can not reproduce the long startup. If the last build did not improve the startup time, could you ftp-ed to us your very very huge workspace.
Closing as not reproduceable. Also various changes occurred to reduce our startup time (no longer checking index consistency).
