Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defer initialization of classpath to the background if called from main #1525

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

laeubi
Copy link
Contributor

@laeubi laeubi commented Dec 17, 2024

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 #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
@vogella
Copy link
Contributor

vogella commented Dec 17, 2024

I'm very happy to see that you working on the startup performance of Eclipse @laeubi Thank you.

Copy link

Test Results

  272 files   -    13    272 suites   - 13   38m 29s ⏱️ - 15m 45s
3 586 tests ±    0  3 509 ✅  -     1   76 💤 ± 0  1 ❌ +1 
7 972 runs   - 2 978  7 818 ✅  - 2 901  153 💤  - 78  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 4639a5e. ± Comparison against base commit 85ceed2.

Copy link
Member

@HannesWell HannesWell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you Christoph for working on this issue, I'm very happy about that as well.
But the presented solution does seem to be very robust and I don't think pde.core should handle issues that arise from wrong usage in the UI. Therefore I would prefer a solution in the UI classes where this is caused. E.g. the editor should defer the initialization to a background thread. I would like to have this only as a last resort solution.

Job job = JOB_MAP.get(javaProject);
if (job != null) {
try {
job.join();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this have the effect that the method blocks again until the classpath-set returns?
How would this then improve the start-up performance? Or is it just done to resolve dead-locks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This codepath is only executed when it is called outside the UI (e.g. in a build thread) where it is fine to block, the goal is to join on a possible execution that previously was scheduled in an UI thread.

@laeubi
Copy link
Contributor Author

laeubi commented Dec 18, 2024

But the presented solution does seem to be very robust and I don't think pde.core should handle issues that arise from wrong usage in the UI.

It is not nice but reflects reality in Eclipse IDE runtime environment and we can quite easy remove it once a better solution is there. Also there are sadly numerous places (and maybe some unknown places) where this happens and at least we get a warning in the log now when new things arise.

@laeubi
Copy link
Contributor Author

laeubi commented Dec 18, 2024

Interestingly the warning even triggers in the CI build already :-D

https://ci.eclipse.org/pde/job/eclipse.pde/job/PR-1525/2/maven-warnings/new/source.b23f7a3a-eedd-4a60-b012-8767a6761747/#6521

@jukzi
Copy link
Contributor

jukzi commented Dec 18, 2024

Thanks for working on the issue. But i think one should not make decisions based on thread name. Better solve it in the caller.

@laeubi
Copy link
Contributor Author

laeubi commented Dec 18, 2024

Thanks for working on the issue. But i think one should not make decisions based on thread name. Better solve it in the caller.

Will you propose PR to do so for JDT?

And as mentioned before the worst that can happen is it will work as before, so there is no real "danger" in this decision.

@jukzi
Copy link
Contributor

jukzi commented Dec 18, 2024

Will you propose PR to do so for JDT?

no, but that is no reason to introduce dirty hacks.

@laeubi
Copy link
Contributor Author

laeubi commented Dec 18, 2024

Will you propose PR to do so for JDT?

no, but that is no reason to introduce dirty hacks.

This is not a dirty "hack" it is a workaround for the situation that is is very unlikely that changes will occur any time soon in an unrelated project (JDT) as it is "understaffed" (as every other project as well... So if we can improve the situation quite easy and make it better for all users of PDE there is no reason to wait for something that maybe never happens.

And even if it does, we can easily remove the code again without any problem.

@vogella
Copy link
Contributor

vogella commented Dec 18, 2024

I agree that we should apply this PR.

PDE should protect itself from bad callers which seems to be in this case JDT.

@iloveeclipse
Copy link
Member

I agree that we should apply this PR.
PDE should protect itself from bad callers which seems to be in this case JDT.

I'm not sure you understand possible implications of that PR. JDT will see classpath containers that are not fully initialized or use containers that can't be initialized at all. This may lead to unpredictable plugin compilation results.

Please check org.eclipse.jdt.core.ClasspathContainerInitializer.initialize(IPath, IJavaProject) javadoc and org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(IJavaProject, IPath) code.

I agree with @jukzi this is a dirty hack and dangerous one too.

@laeubi
Copy link
Contributor Author

laeubi commented Dec 18, 2024

I'm not sure you understand possible implications of that PR. JDT will see classpath containers that are not fully initialized or use containers that can't be initialized at all. This may lead to unpredictable plugin compilation results.

When the computation is done, we notify JDT that something has changed and then it will simply reevaluate. Also as compilation does not happen in the UI thread for this case nothing changes at all, this all calling from the UI is as far as I can see only to inspect the classpath entries and the init of the container is just a side-effect.

Also as you mention the javadoc it says:

Binds a classpath container to a IClasspathContainer for a given project,
or silently fails if unable to do so.

So it would be even valid to do nothing and simply return, I just wanted to be a little bit nice here ;-)

I would be happy to not require this so I suggest anyone who feels uncomfortable with this put a breakpoint in

org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(IJavaProject, IPath)

and fix all call sites that enter her in the main (== UI thread) when you start an eclipse, sadly those are very deep nested so its not trivial, and obviously those are not compile threads in any case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JDT calls PDE Classpath on startup with open Editor hindering the UI to show up
5 participants