Closed haubi closed 2 years ago
do you have any idea how to resolve this?
can you also test with platform 4.24 M1 and Xtext 2.27.0.M1 https://github.com/eclipse/xtext-eclipse/issues/1820
cc @iloveeclipse. was there anything changed about "project information may not be restored from saved Eclipse state yet"
@haubi is this related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=568324 ?
2021-06 has already https://bugs.eclipse.org/bugs/show_bug.cgi?id=568324
With 2021-06 I have neither discovered nor debugged this situation, but I can imagine just the timing between these threads to be different there to not trigger this problem. As far as I understand from it's description, https://bugs.eclipse.org/bugs/show_bug.cgi?id=568324 may indeed be related.
cc @jukzi for (helping me to) eventually test with more recent platform and Xtext
Hard to say what could be changes in last few years especially if startup timing is the problem. If one could at least find the exact release... There were lot of changes that might affect startup timing / order in entire SDK.
But if Storage2UriMapperJavaImpl
requires JDT to be initialized, may be better to search for the solution.
If this code in Xtext starts before JDT is fully initialized, the question is: what is "fully initialized JDT state" that is needed by Storage2UriMapperJavaImpl
. #1836 however looks like a hack.
i guess you only just faced https://bugs.eclipse.org/bugs/show_bug.cgi?id=578968
i guess you only just faced https://bugs.eclipse.org/bugs/show_bug.cgi?id=578968
Indeed! And the original report is talking about Xtext as well: https://bugs.eclipse.org/bugs/show_bug.cgi?id=578564
Thanks a lot! (closing)
So I do have annoying runs of the auto build here for ~10min when restarting Eclipse despite everything was built up to date just before the restart - on Linux with our application having >500 projects and >50k source files:
The culprit is that "Storage2UriMapperJavaImpl::doInitializeCache" thread may run before the "Initializing Java Tooling" thread. Because of being early, project information may not be restored from saved Eclipse state yet. Hence, projects are set up from scratch to some degree, ending up with calls to
Project.touch()
. The result is a modifiedResourceInfo.charsetAndContentId
on the working tree projects, causing builders to be out of date for no good reason.When using a breakpoint in
Storage2UriMapperJavaImpl.doInitializeCache
to wait for the "Initializing Java Tooling" thread to finish,Project.touch()
is not called any more, and the builders remain up to date as restored from saved Eclipse state.Stack trace of
ResourceInfo.incrementContentId()
being called in "Storage2UriMapperJavaImpl::doInitializeCache" thread: