Community
Participate
Working Groups
master, already happens in 4.7 M4, was OK in M2 Launching a class takes takes much long than it used to. Steps: - new workspace - paste snippet: package p; public class C { public static void main(String[] args) { String name= String.class.getName(); System.out.println(name); } } - click "Debug" toolbar button => Dialog says I have to wait for the index. That's OK. => Another dialog says "Creating type hierarchy for p.C". It's not OK that this delays the launching by several seconds. Problem could be the new index in JDT Core.
Yes, I have been observing this after the the new indexer.
Agree that launching should be faster, not slower, using the new index. Here's an educated guess as to what's going on: With the code in its current state (the legacy indexer and new indexer are running in parallel), waiting on the index means waiting for both indexers to finish... so when creating a new workspace, this means waiting twice as long before stuff starts responding. Currently, all consumers of the search and type hierarchy APIs make use of the blocking variant (which waits for the indexer). Anything that opens UI should be using the nonblocking variant. That can make a best effort guess while the indexer is running and then correct itself after it's done. I'll post more comments once I investigate further (which should happen after the index fragmentation bugs are sorted out).
I didn't look at the code, so this is just an educated guess: Creating a supertype hierarchy used to be pretty cheap in the past. IIRC, that didn't even need an up-to-date index. Maybe launching creates a supertype hierarchy and that is waiting for the index now?
Sorry for taking so long to come back to this, Markus. I've put my fragmentation work on hold for the past week to sort out the index corruption bug you filed. Now that that's fixed I can get back to fixing the fragmentation issues. This is still the next-most-important item after that.
Still facing the issue.
Yeah, sorry. I haven't had time to circle back to it yet. I'm not done fixing the fragmentation bug yet (see bug 512921 for status) and two deadlocks were also discovered in the Jobs framework that will have to go before this.
Does not happen any more in I20170508-2000 (where the new index is disabled out of the box). To reproduce, you have to enable the new index, e.g. by appending this line to path-to-I20170508-2000/plugins/org.eclipse.sdk_4.7.0.v*/plugin_customization.ini: org.eclipse.jdt.core/enableNewJavaIndex = true
Hopefully it will be fixed in 4.8
How can the new index be disabled? I'm facing this bug in 4.6.3 in an IBM product. I cannot find the preference to disable it.
(In reply to Wim Jongman from comment #9) > How can the new index be disabled? I'm facing this bug in 4.6.3 in an IBM > product. I cannot find the preference to disable it. Apologies. It is not available in 4.6.3. In 4.6.3, I am waiting about 2 minutes before the class actually launches. So it might not be a problem with the new indexer after all.
Moving out. Someone else will have take this up if required.
Having the same issue in 4.7.3. This also happens when launching JUnit tests, not just debug. Sometimes 'Creating type hierarchy...' consumes large amounts of memory (2G+) and takes several minutes to launch (I believe because it's memory starved and GC thrashing). Was not a problem in our previous 4.6.1 eclipse bundle.
I've run into this problem with 4.9 when launching JUnit tests (I have hundreds of them) and a type hierarchy with cycles/constrained type arguments: https://github.com/ReactiveX/RxJava. It worked without any noticeable delay in 4.7.3a. Eclipse Java EE IDE for Web Developers. Version: 2018-09 (4.9.0) Build id: 20180917-1800
Can you check if new java indexer is enabled?
The "Use new Java indexer" option is disabled in both 4.7.3a and 4.9.
(In reply to David Karnok from comment #15) > The "Use new Java indexer" option is disabled in both 4.7.3a and 4.9. Which Junit version are you using ? Are you getting this message "Creating type hierarchy..." ? Does it work with Eclipse 4.8 ?
> Which Junit version are you using ? 4.12 > Are you getting this message "Creating type hierarchy..." ? Yes, that message is showing on the status bar for 30-60 seconds. > Does it work with Eclipse 4.8 ? It takes 30-60 seconds in 4.8 as well.
I've tried with : eclipse-SDK-4.7.3a-linux-gtk-x86_64.tar.gz eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz I'm not really seeing any noticable difference in time taken to finally launch the java snippet from the bug description. I am seeing the progress dialog come up for some search operations relating the the JRE libraries. My guess is that the debug operation is held up by indexing (JRE, and the pasted code). In fact I can clearly see that once write operations to $WORKSPACE/.metadata/.plugins/org.eclipse.jdt.core quiet down, clicking debug completes almost instantly.
Just to confirm, @David do you see this only the first time or every time you launch ?
Yes, it is slow every time I launch the tests.
(In reply to David Karnok from comment #20) > Yes, it is slow every time I launch the tests. To me it looks like a different issue then as indexer related regression should impact only the first run. Can you please create a bug in JDT UI as it handles the junit test launching.
(In reply to David Karnok from comment #13) > It worked without any noticeable delay in 4.7.3a. JUnit 5 changes were added in Eclipse 4.7.1a and also you are facing it with JUnit 4 test cases itself. So my guess is that it should not be related to those changes. Since the difference can be seen between 4.7.3a and 4.8, some change in between these two releases seems to be causing this. David, is it possible for you to provide your code setup so that we can reproduce the issue? It doesn't happen in normal cases. I guess you will not have access to the 4.8 milestone builds. If that was possilble then you could narrow it down to the milestone where the issue started happening. (In reply to David Karnok from comment #20) > Yes, it is slow every time I launch the tests. Just to re-confirm, do you see the slowness and the "Creating type hierarchy..." message every time you re-run your tests (without restarting Eclipse or deleting/resetting the index)? This could mean that the index is being reset before every run.
> David, is it possible for you to provide your code setup so that we can reproduce the issue? Happens for me with 4.9 and the project https://github.com/ReactiveX/RxJava It contains more than 10.000 test methods so the slowness is quite apparent for me (i7 4790, Windows 10, Java 8u192). It could be related to Gradle/Buildship though as the project is using Gradle, even though the "Run as JUnit test" should by no means interact with Gradle. This slowness didn't happen in 4.7.3a and Spring Gradle STS plugin. > Just to re-confirm, do you see the slowness and the "Creating type hierarchy..." message every time you re-run your tests (without restarting Eclipse or deleting/resetting the index)? Yes. - I right-click on the project and chose Run > JUnit tests - Wait for "Creating hierarchy..." - Tests start and run to completion - I right-click on the project and chose Run > JUnit tests again - Wait for "Creating hierarchy..." again - Tests start and run to completion again
> Since the difference can be seen between 4.7.3a and 4.8, some change in between these two releases seems to be causing this. We have the problem in 4.7.3, so it's from before that. Eclipse 4.7.3, junit 4.12, mockito 1.10.19, hamcrest 1.3, gradle 4.7, buildship 2.2.1. We didn't use 4.7.2 much but doing a quick check it also exhibits the same issue. 4.7.2 is when we upgraded to gradle 4.7 with buildship. Prior to that we were on 4.6.1 with gradle 2.10 and the STS gradle plugin and did not have the issue.
1. Launched eclipse with -clean -refresh 2. Run As > JUnit Test on my project 3. Progress spends ~3.5m on "Launching Java: Creating type hierarchy..." 4. Console is allocated, tests start and run to completion 5. Click the JUnit Rerun test icon 6. Progress spends ~3.5m on "Launching Java: Creating type hierarchy..." 7. Console is allocated, tests start and run to completion I have another spring-boot project that does not exhibit this behavior. That project has a shallower includeFlat project stack of just 1 upstream project. However, it also has a lot fewer tests, ~200. The "slow" spring-boot project: * Has a deeper includeFlat project stack with 7 upstream projects. * Removing the includeFlat and using jar artifacts instead of projects had no affect. * Has about 2500 unit tests and 700 int tests. * The slowness only occurs when running test at the project level or sourceSet/java level. Presumably that's because it's scanning more than just a single package. * No errors are reported on the Error Log view. * Running just the 700 intTests takes ~1m to create the hierarchy. * Running just the 2500 unit tests takes ~2m to create the hierarchy. * Running all 3200 tests at the project level takes ~3.5m to create the hierarchy.
Created attachment 276456 [details] Sample project Maybe this sample project will help identify the problem. 1. Extract the test-app project 2. Import it a gradle project 3. Run the gradle build generateTests to create 2000 sample/test/Test#.java files with 10 @Tests per file. 4. Open Progress view. 5. Run tests for the project.
Possibly a gradle issue as well? We will try to reproduce but in the mean time you can check with the gradle community as well.
(In reply to Sarika Sinha from comment #27) > Possibly a gradle issue as well? > We will try to reproduce but in the mean time you can check with the gradle > community as well. I'm sure gradle is a red herring (i.e. not the cause). Let's not chase that. It is also not related to the new indexer because this problem already appeared before the new indexer was introduced.
Yes, it does not look like new indexer issue, that is why I asked to create another bug !! But it is a possibility that gradle is clearing the cache as you are getting the message "Creating type hierarchy" for each launch execution. Index is created once and this message should not come again unless index was cleared.
(In reply to Sarika Sinha from comment #29) > Yes, it does not look like new indexer issue, that is why I asked to create > another bug !! Why create another bug? > But it is a possibility that gradle is clearing the cache as you are getting > the message "Creating type hierarchy" for each launch execution. Index is > created once and this message should not come again unless index was cleared. Everything is possible, but since the early comments are not related to gradle, I would not jump on it. I am not using gradle but still I see the problem every once in a while. Especially when pasting a new snippet. I haven't seen it recently but I have my eyes open for it.
Here is the stack I see when stuck on the "creating type hierarchy" dialog while trying to run a class "ModalContext" #4130 prio=6 os_prio=0 tid=0x00007f47e99be800 nid=0x5aea in Object.wait() [0x00007f47fca0d000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(java.base@10.0.2/Native Method) - waiting on <no object reference available> at org.eclipse.core.internal.jobs.Semaphore.acquire(Semaphore.java:42) - waiting to re-lock in wait() <0x00000000f5f0e060> (a org.eclipse.core.internal.jobs.Semaphore) at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:911) at org.eclipse.core.internal.jobs.InternalJob.join(InternalJob.java:348) at org.eclipse.core.runtime.jobs.Job.join(Job.java:608) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.waitForIndex(Indexer.java:1025) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.waitForIndex(Indexer.java:1046) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.newSearchAllPossibleSubTypes(IndexBasedHierarchyBuilder.java:514) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.searchAllPossibleSubTypes(IndexBasedHierarchyBuilder.java:499) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.determinePossibleSubTypes(IndexBasedHierarchyBuilder.java:456) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:157) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:323) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1319) - locked <0x00000000f5f00bb8> (a org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802) at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:887) at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:844) at org.eclipse.jdt.internal.debug.ui.launcher.MainMethodSearchEngine.addSubtypes(MainMethodSearchEngine.java:129) at org.eclipse.jdt.internal.debug.ui.launcher.MainMethodSearchEngine.searchMainMethods(MainMethodSearchEngine.java:106) at org.eclipse.jdt.internal.debug.ui.launcher.MainMethodSearchEngine$1.run(MainMethodSearchEngine.java:166) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) I still question why building the type hierarchy is necessary at that point. Sure, it can be indexer taking too long, but why do we even need to ask it anything at that point?
(In reply to Mickael Istria from comment #31) > > I still question why building the type hierarchy is necessary at that point. > Sure, it can be indexer taking too long, but why do we even need to ask it > anything at that point? There is a dialog shown for user to select the type to launch if there are main classes existing in the SubTypes.
(In reply to Sarika Sinha from comment #32) > There is a dialog shown for user to select the type to launch if there are > main classes existing in the SubTypes. As a Java developer, if I select a class that has a main() and call Run As > Java Application, I expect the IDE to just start that main. I think the handling of the Rus As can be improved at least in that case to perform the expected behavior without computing a Type Hierarchy.
(In reply to Mickael Istria from comment #33) > (In reply to Sarika Sinha from comment #32) > > There is a dialog shown for user to select the type to launch if there are > > main classes existing in the SubTypes. > > As a Java developer, if I select a class that has a main() and call Run As > > Java Application, I expect the IDE to just start that main. > I think the handling of the Rus As can be improved at least in that case to > perform the expected behavior without computing a Type Hierarchy. I think we are just moving away from the main issue here !! Even if we decide to show/not show the dialog while launching, it should not be to just postpone the indexing to some other time.
(In reply to Sarika Sinha from comment #34) > (In reply to Mickael Istria from comment #33) > I think we are just moving away from the main issue here !! This is the issue. Launching of the class takes too long. I agree with Mickael that there should be no queries for subclasses. The underlying problem may not be fixed but that is a different issue altogether that may or may not pop-up somewhere else. Also when launching on the package level there should be no query for subclasses, just show the classes with main methods that are in the package. What is the use case anyway? It sounds over-engineered to me.
I just now got this - An internal error occurred during: "Computing type hierarchy of 'org.eclipse.jdt.ui'...". So the problem needs to be fixed and not the symptom alone.
(In reply to Sarika Sinha from comment #36) > I just now got this - > An internal error occurred during: "Computing type hierarchy of > 'org.eclipse.jdt.ui'...". > > So the problem needs to be fixed and not the symptom alone. This did not happen during launching. Will be analyzing on the general slowness of type hierarchy first and then we can decide what action should be taken.
(In reply to Sarika Sinha from comment #37) > An internal error occurred during: "Computing type hierarchy of > 'org.eclipse.jdt.ui'...". Don't you agree that this internal error should be fixed in another bug with this bug as a blocker? ;)
I was directed here from https://www.eclipse.org/forums/index.php/t/1098501/ My problem does not seem exactly like the ones described here as I do not see it while using Java8; only when use Java11, but the symptoms are identical. That is, a very long time spent in "creating type hierarchy". By switching the JDK version back and forth between jdk1.8 and openjdk11 inside Eclipse 2018-12, I can get the problem (with 11) and remove the problem (with 1.8). As there also was some discussion in this thread related to gradle, I can add my 2 cents that at least for me, this isn't the problem. I tried with and without gradle nature on the project and I get the same issue in both cases. Also, the bug is listed on the "debug" component, but I see this on "run" so I can't say if this is the same thing or not. Unfortunately, I can't share the project as it is company-internal, but let me know if there's any more information I can provide or something I can test.
Based on the experience from our project, this problem is nearly a deal-breaker for us, it severely hinders our way of working. But since there aren't a lot of people yelling about it or the related bug, I guess that means that only a few projects are hit by it. Is there any plans to work on this bug before next release? What we ended up doing was creating a custom junit suite runner that does the test discovery based on scanning the classpath for specific package prefixes, which does the discovery in about 1-2 seconds instead of 60+ seconds. It allows us to keep working, but it is a bit odd to not be able to run the tests in the regular eclipse way. But since the above is possible to do, I'm not sure why Eclipse even has to do such a slow process to discover testcases. Why does it even have to build a class hierarchy dynamically while launching? Isn't the information about tests already in the index that eclipse builds first time I do "open type"? What information does it get that isn't already in the index? I haven't looked much at any Eclipse source code, so I suspect I wouldn't be much use in trying to help out with any fix to the bug, but I might have time to try something if anyone has some pointers where to get started.
https://www.eclipse.org/forums/index.php/t/1098501/ Looks definitely different than the original problem reported in this bug which was due to the new Indexer. The new problem looks like a manifestation of some change in type hierarchy calculation for modular projects. Will need some input from a JDT core person. I have created Bug 546852 to Investigate the need of hierarchy calculation during launching.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
