Bug 547833 - [content assist] Chain Completion enabled automatically, too slow, causes freezes
Summary: [content assist] Chain Completion enabled automatically, too slow, causes fre...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 blocker (vote)
Target Milestone: 4.12 RC2   Edit
Assignee: Andrey Loskutov CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on: 544108
Blocks:
  Show dependency tree
 
Reported: 2019-06-01 03:48 EDT by Ed Willink CLA
Modified: 2019-12-18 11:19 EST (History)
3 users (show)

See Also:
daniel_megert: pmc_approved+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2019-06-01 03:48:54 EDT
I upgraded to M3 yesterday, builds and tssts seemd ok. Today deugging / editing is a disaster.

2019-03 had some form of PDE completion proposal hang that was really irritating but just tolerable.

This has now got much worse. Close to unuseable. Reverting to 2019-03.

One error log is:

The 'org.eclipse.jdt.ui.org.eclipse.jdt.ui.javaCompletionProposalComputer.chain' proposal computer from the 'org.eclipse.jdt.ui' plug-in did not complete normally. The extension took too long to return from the 'computeCompletionProposals()' operation.

One UI hang is:

Stack Trace
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:11890)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12352)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.parseStatements(MethodDeclaration.java:198)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.parseMethods(TypeDeclaration.java:951)
	at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:11036)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:878)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:909)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:614)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:832)
	at org.eclipse.jdt.core.dom.ASTParser.createBindings(ASTParser.java:1075)
	at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.resolveBindingsForTypes(TypeBindingAnalyzer.java:357)
	at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.getTypeBindingFrom(TypeBindingAnalyzer.java:267)
	at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.findFieldsAndMethods(TypeBindingAnalyzer.java:100)
	at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.findVisibleInstanceFieldsAndRelevantInstanceMethods(TypeBindingAnalyzer.java:86)
	at org.eclipse.jdt.internal.ui.text.ChainFinder.findAllFieldsAndMethods(ChainFinder.java:146)
	at org.eclipse.jdt.internal.ui.text.ChainFinder.searchDeeper(ChainFinder.java:132)
	at org.eclipse.jdt.internal.ui.text.ChainFinder.searchChainsForExpectedType(ChainFinder.java:81)
	at org.eclipse.jdt.internal.ui.text.ChainFinder.startChainSearch(ChainFinder.java:58)
	at org.eclipse.jdt.internal.ui.text.java.ChainCompletionProposalComputer.lambda$0(ChainCompletionProposalComputer.java:158)
	at org.eclipse.jdt.internal.ui.text.java.ChainCompletionProposalComputer$$Lambda$836/1181573674.run(Unknown Source)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Comment 1 Andrey Loskutov CLA 2019-06-01 03:52:55 EDT
Ed, did you had "Chain Template Proposals" enabled?
This one should be *in theory* disabled by default (Preferences -> Java -> Editor -> Content Assist -> Advanced).

Please make sure it is disabled and try again. If the problem reoccurs, please provide your error log.
Comment 2 Andrey Loskutov CLA 2019-06-01 03:55:06 EDT
See bug 544108 comment 39.
Comment 3 Ed Willink CLA 2019-06-01 03:56:46 EDT
After reverting to 2019-03 I get a some content proposals have been uninstalled. I took the restore defaults path. Back to useable.

Looks as if an addition for 2019-06 is not yet ready for prime time.

(In reply to Andrey Loskutov from comment #1)
> Ed, did you had "Chain Template Proposals" enabled?

No idea if enabled or not and no idea what they might be. I certainly didn't adjust any setting. I just changed my 4.11 shortcut to 4.12M3 and started on the new release with the old workspace; just as I normally do.
Comment 4 Andrey Loskutov CLA 2019-06-01 03:58:11 EDT
(In reply to Ed Willink from comment #3)
> (In reply to Andrey Loskutov from comment #1)
> > Ed, did you had "Chain Template Proposals" enabled?
> 
> No idea if enabled or not and no idea what they might be. I certainly didn't
> adjust any setting. I just changed my 4.11 shortcut to 4.12M3 and started on
> the new release with the old workspace; just as I normally do.

Ed, as said, please check this under Preferences -> Java -> Editor -> Content Assist -> Advanced.
Comment 5 Ed Willink CLA 2019-06-01 04:21:22 EDT
(In reply to Andrey Loskutov from comment #4)
> Ed, as said, please check this under Preferences -> Java -> Editor ->
> Content Assist -> Advanced.

Changing to 4.12M3 again and comparing the 4.12M3 and 4.11 dialog, the only difference I see is a not-checked Chain Template Proposals in both selection panes. 4.12M3 completion assist now seems reasonable. If I explicitly select Chain Template Proposals, completion assist renders editing unuseable again.

So yes, it looks like the new Chain Template Proposals is not fit for prime time, so we have two problems.

a) Why do Chain Template Proposals make editing unuseable
b) why was Chain Template Proposals functionality enabled by an upgrade that just re-used an old workspace on a new installation?
Comment 6 Dani Megert CLA 2019-06-01 06:22:45 EDT
We could even consider this critical or even blocker.
Comment 7 Ed Willink CLA 2019-06-01 09:27:34 EDT
Perhaps my usage was not as anticipated. Having looked at the documentation, it is all based on completion i.e.

... = $
}

where $ is the completion point at the end of something plausible with a } to give a clear context. I was doing something like:

  System.out.println(projectMap.getClass().getSimpleName() + "-"
   +  projectMap.$instanceCount + ": install EPackageDescriptor-"
   + instanceCount + " for '" + uri + "'");

to investigate available names. But the expected type is String and so there are of course gazillions of possibilities. I thing I also tried where the expected type is Class.

Similarly I find Completion Assist really bad for 're-completion'

e.g. at     xxx.yyy$aaa(zzz)

then selecting yyybbb(...) from the offerings always leaves me with at least the syntax error

xxx.yyybbb(args)(zzz)

and sometimes

xxx.yyybbbaaa(bbbargs)aaa(zzz)

Has in-place re-completion not been considered?
Comment 8 Andrey Loskutov CLA 2019-06-01 15:44:47 EDT
(In reply to Dani Megert from comment #6)
> We could even consider this critical or even blocker.

I can't reproduce with a fresh 4.11 workspace and all default settings.

BUT.

I can reproduce with a fresh 4.11 workspace where I first select *everything* in any table on the Preferences -> Java -> Editor -> Content Assist -> Advanced dialog. Using *that* workspace with 4.12 I see that again, all values in this table (except "Java Type Proposals" and "Java Non-Type Proposals") are selected, *including* "Chain Template Proposals".

Note: looks like "Java Type Proposals" and "Java Non-Type Proposals" saving is broken - once enabled, they show up enabled during the same session, but after restart they are always disabled. I'm not sure if this expected and some strange feature???
Comment 9 Andrey Loskutov CLA 2019-06-01 17:08:44 EDT
(In reply to Andrey Loskutov from comment #8)
> I can reproduce with a fresh 4.11 workspace where I first select
> *everything* in any table on the Preferences -> Java -> Editor -> Content
> Assist -> Advanced dialog. Using *that* workspace with 4.12 I see that
> again, all values in this table (except "Java Type Proposals" and "Java
> Non-Type Proposals") are selected, *including* "Chain Template Proposals".

OK. Looking on the code, it is enough to change *something* in the JDT codeassist preferences, so that the preference value is changed and persisted - as soon as the PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted, defaults for exclusion do not work anymore - and so *any* new proposal introduced as "excluded by default" is NOT excluded by default.

The entire concept is not working here. We need to know *both* user included and excluded categories, so that for values not existing in the both lists defaults could be applied.

> Note: looks like "Java Type Proposals" and "Java Non-Type Proposals" saving
> is broken - once enabled, they show up enabled during the same session, but
> after restart they are always disabled. I'm not sure if this expected and
> some strange feature???

This seem to be a side effect of the fix for bug 250629, which is a bug but unrelated to the current problem.
Comment 10 Andrey Loskutov CLA 2019-06-01 17:34:36 EDT
(In reply to Andrey Loskutov from comment #9) 
> OK. Looking on the code, it is enough to change *something* in the JDT
> codeassist preferences, so that the preference value is changed and
> persisted - as soon as the
> PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted,
> defaults for exclusion do not work anymore - and so *any* new proposal
> introduced as "excluded by default" is NOT excluded by default.

I think we have two choices: remove the feature from 4.12 (probably we can simply comment out plugin.xml contribution) or introduce a quick and dirty hack in org.eclipse.jdt.ui.PreferenceConstants.initializeDefaultValues(IPreferenceStore) to check if we have started 4.12 for the first time and if that is the case, re-write user value of PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES to the ${user value} + org.eclipse.jdt.ui.javaChainProposalCategory.

Looking on the current issues with the new proposal, and with the problem that the hack will need to be left *forever* in the code, I would vote for "hiding" the new feature from 4.12. I will push a patch in a moment. I think we can't risk to break content assist for Java so badly, this will be not acceptable for our users.

> The entire concept is not working here. We need to know *both* user included
> and excluded categories, so that for values not existing in the both lists
> defaults could be applied.

This need to be done after 4.12, the change will require more rework as allowed for 4.12.
Comment 11 Eclipse Genie CLA 2019-06-01 17:41:03 EDT
New Gerrit change created: https://git.eclipse.org/r/143167
Comment 12 Ed Willink CLA 2019-06-02 03:50:12 EDT
(In reply to Ed Willink from comment #5)
> Changing to 4.12M3 again 

My workspace has been backwards and forwards across many tens, possibly hundreds, of Eclipse releases in the last 4 years.
Comment 13 Stephan Herrmann CLA 2019-06-02 17:14:41 EDT
Just a small side issue: 

(In reply to Ed Willink from comment #7)
> Has in-place re-completion not been considered?

Please see the first radio buttons below
  Preferences > Java > Editor > Content Assist > Insertion

By default you can let completion overwrite by pressing Ctrl+Return instead of plain Return.
Comment 14 Dani Megert CLA 2019-06-03 02:49:57 EDT
(In reply to Andrey Loskutov from comment #10)
> (In reply to Andrey Loskutov from comment #9) 
> > OK. Looking on the code, it is enough to change *something* in the JDT
> > codeassist preferences, so that the preference value is changed and
> > persisted - as soon as the
> > PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted,
> > defaults for exclusion do not work anymore - and so *any* new proposal
> > introduced as "excluded by default" is NOT excluded by default.
> 
> I think we have two choices: remove the feature from 4.12 (probably we can
> simply comment out plugin.xml contribution) or introduce a quick and dirty
> hack in
> org.eclipse.jdt.ui.PreferenceConstants.initializeDefaultValues(IPreferenceStore)
> to check if we have started 4.12 for the first time and if that is the case,
> re-write user value of PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES to
> the ${user value} + org.eclipse.jdt.ui.javaChainProposalCategory.
> 
> Looking on the current issues with the new proposal, and with the problem
> that the hack will need to be left *forever* in the code, I would vote for
> "hiding" the new feature from 4.12. I will push a patch in a moment. I think
> we can't risk to break content assist for Java so badly, this will be not
> acceptable for our users.
> 
> > The entire concept is not working here. We need to know *both* user included
> > and excluded categories, so that for values not existing in the both lists
> > defaults could be applied.
> 
> This need to be done after 4.12, the change will require more rework as
> allowed for 4.12.
+1. It's not just content assist itself, but it will also make people not use/try chain completion in the future.
Comment 15 Dani Megert CLA 2019-06-03 02:52:06 EDT
Please see my comment in the Gerrit change. You need to test what happens for users that have it already enabled, either by accident or explicitly.
Comment 16 Andrey Loskutov CLA 2019-06-03 03:42:33 EDT
(In reply to Dani Megert from comment #15)
> Please see my comment in the Gerrit change. You need to test what happens
> for users that have it already enabled, either by accident or explicitly.

To keep this on the bug:

The user will see *once* a dialog:

"Content Assist Problem" - "Some content proposal kinds have been uninstalled. It is recommended to review content assist settings" - <Link to settings> / <Restore Default> |<Close>.

Neither "Close" not "Restore Defaults" do anything bad, also after restart. The dialog shows up on first content assist invocation, the code in org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.updateUninstalledComputerCount() notices that the remembered number of proposals doesn't match and later dialog is shown.

So from my POV, this is works as expected.
Comment 17 Ed Willink CLA 2019-06-03 03:45:52 EDT
I feel that the philosophy has gone wrong.

It is inevitable that cleverer and cleverer completion computations will make Eclipse slower and slower for proposals that have lower and lower probability of utility. Give the user control. No cost by default, incur the cost on demand.

There is also a naive assumption that the completion proposal computation knows what to do, which for chains implies an ability to empathize the target type. What if the code is rubbish. How do I search for a chain then? Either I create a dummy target variable, or better give me a dialog.

For smart proposals, let there be a Smart Quick Fix dialog, where I can tunnel down to chains and configure its target type, overriding the deduced type if needed, and enabling interface-2-implementation cast on traversals if I want insight into what might be possible with actual types. The cycling through pages of proposals was ok for 2 perhaps 3 alternatives. I never look at the extra pages since they never seem to achieve anything apart from confusing me when some how one has been selected. It just does not scale for 8 or more... Trees are better.
Comment 18 Eclipse Genie CLA 2019-06-03 09:23:42 EDT
New Gerrit change created: https://git.eclipse.org/r/143204
Comment 21 Andrey Loskutov CLA 2019-06-03 09:27:38 EDT
Disabled contribution and removed N&N. Will re-open & re-target 544108. Will close after the patch is available for validation.
Comment 22 Dani Megert CLA 2019-06-04 03:45:54 EDT
Verified with I20190603-1800 that chain completion is not available.