JDT calls PDE Classpath on startup with open Editor hindering the UI to show up #1481
Comments
|
maybe related to or duplicate of #1160 |
|
I also sampled the process a bit, snapshot: |
|
Maybe an infinite loop waiting for org.eclipse.equinox.internal.p2.transport.ecf.FileInfoReader.barrier |
|
created eclipse-equinox/p2#568 |
|
I have took a look into this and the case is actually (apart from deadlock or not) that the initialization of a Java editor calls into PDE that then resolves the target. I have reproduced the case and it is very bad behavior because currently an open Java Editor means a lot of things are done before even the IDE ever opens:
Now many non trivial things happen the most "bad one" seem that we enter: org.eclipse.jdt.internal.core.DeltaProcessor.fire(IJavaElementDelta, int) what synchronously calls listeners that update the org.eclipse.jdt.internal.core.PackageFragmentRoot.getRawClasspathEntry() that has this line
that then triggers PDE target resolution in the UI thread and before the IDE has a chance to start! I have opened:
|
laeubi
changed the title
|
If I disable all mentioned places my IDE starts up even if I put a breakpoint in |
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
An easy way to get the rough startup time is to start Eclipse with the -debug and -data flag, e.g. eclipse -data ~/workspace/test -debug You will see the total startup time in the console. To activate tracing for startup time by bundle you have to add two options to an .options file, see https://www.vogella.com/tutorials/EclipsePerformance/article.html#example-tracing-the-startup-time-of-plug-ins |
|
@jukzi would it be possible in JDT(-UI) to 'just' defer the heavy initialization done for an editor to a background thread, to solve this issue at it's root? See also my comment in #1525 (review). |
sure, just propose a solution for eclipse-jdt/eclipse.jdt.ui#1860 |
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently increase time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
|
As analysis has shown this is not a PDE but JDT issue, so if anything is left pleas reopen there. |
Currently there are some bad behaving UI components in the eclipse IDE that trigger resolving of the classpath containers in the process of creating the UI, this leads to very bad startup performance and even deadlocks in startup. This now detects the issue, logs a warning of the offending component and defer the initialization of classpath to a background job, this currently decrease time from starting eclipse until UI is shown noticeable. Fix eclipse-pde#1481
|
I have now further investigated why the deadlock itself occurs, the reason is that
is calling now you get to the unlucky state that the |
Because of possible deadlock when Javaeditor from JDT calls PDE calls OOMPH calls P2 to download new target platform waiting for a Job that is not executed because JobManager is suspendend eclipse-pde/eclipse.pde#1481 Was already suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=514090
Because of possible deadlock when Javaeditor from JDT calls PDE calls OOMPH calls P2 to download new target platform waiting for a Job that is not executed because JobManager is suspendend eclipse-pde/eclipse.pde#1481 Was already suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=514090 Old behavior can be used by setting VM property -Dorg.eclipse.ui.suspendJobManagerDuringStart=true
|
Now we see the following Stacktrace when the problem occurs: @jukzi is there any way out of this state or is it permanent? |
|
What I did now was:
As an alternative, delete "workbench.xmi" but one would loose all customizations :-\ |
I don't know any way for the user to cancel it and it happens again on every restart. The user can only select another workspace. |
|
I expect running with Another interesting question is how is it that the current target platform is not resolved upon startup?
Wasn't it resolve before shutdown? |
The target platform needs to be resolved each time the IDE starts (but should be quite fast as everything is cached hopefully). |
|
To answer my own question, it seems a bit of a design flaw in org.eclipse.pde.internal.core.target.AbstractBundleContainer.isResolved() which is final and is effectively the only implementation of ITargetLocation from which all other implementations derive.
These are the only places that set fResolutionStatus to a non-null value:
Oomph targlets support rollback so generally would never need to be (re)resolved on startup. So this unfortunate chain of events is entirely avoidable, though I expect most likely every ITargetLocation suffers from this problem of not being considered resolved initially. |
|
Note when I was in this state in the debugger, nothing got hung up. I'll debug deeper, time permitting. Also note that Oomph has some horrible dirty hacks around this topic: I expect that when the support for composed targets was added to targlets that those are not similarly guarded. As I mentioned, in general there is a profile containing the resolution so we should not need to access the internet but are best off to fall back to the profile or remain in an unresolved state without attempting to access the internet. |
Its an internal class so actually no one ever should derive from it :-P In any case, we can of course remove the But lets assume your |
That's exactly what I did here (before) and where flamed for doing bad things an the whole PDE will go to death: now everyone complains that this never could have happened, so it seem we both are at a very unfortunate alternative time line these days :-P |
Just some things must happen:
but I was not able to trigger this behavior directly as well, I just put some break point in the code to "simulate" a long (or possibly running forever) operation. |
Sometimes Eclipse does not start, but hangs at splash screen:
I am not sure it a real deadlock, but after an hour i stopped waiting.
I am not sure its a PDE problem either, but it feels like it has todo with lock 0x0000000705322ce8 (PluginModelManager.isInitialized) in this example thread dump, but also that org.eclipse.equinox.internal.p2.transport.ecf.FileInfoReader.waitOnSelf in the dump looks odd (what is it waiting for?):
The text was updated successfully, but these errors were encountered: