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
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: