Community
Participate
Working Groups
I am running on todays integration build and it is bordering on unusable due to 3-5 second delays that happen frequently. On taking a VM snapshot, one of the things I noticed was a large number of SelectionListenerWithASTManager jobs. Should there really be that many of these jobs? I have the entire Eclipse base a s source which may be a trigger. Marking as major due to the response times I am seeing (although this may or may not be the cause of that). I will attach the VM trace.
Created attachment 15006 [details] VM dump
Changing to critical. The build is unusable for me.
*** Bug 75651 has been marked as a duplicate of this bug. ***
I just run into this as well (editing ASTProvider.java), the CPU stays at 100% and the stack trace is always at the same place (while creating an AST). Endless loop? org/eclipse/jdt/core/dom/DefaultCommentMapper.storeLeadingComments(DefaultCommentMapper.java:321) This bug uncovered some other minor issues that need to be improved: - instead of n waiting SelectionListenerWithASTManager jobs of which n-1 will be cancelled immediately when invoked only create one waiting job (filed bug 75710) - if the SelectionListenerWithASTManager waits for an AST and the editor closes we should not create an AST for that one but return null (filed bug 75711)
Is there some way to disable this background job? I am still trying to use yesterdays build but too many operations are adversly affected. For example, performing an Open Types (CTRL-SHIFT-T) shows a progress dialog for an extremely long time before opening the types dialog. Others don't seem to have the same issue so I'm wondering if they have some preference configuration that bypasses this problem.
Nothing you can do: the AST gets created during reconcile and this is synchronized with the compilation unit. Every operation that synchronizes on that same CU has to wait.
*** This bug has been marked as a duplicate of 75632 ***
