Community
Participate
Working Groups
The java reconciler comes into play while the user types code and while the compilation process has not kicked in yet to generate the class file. This works fine when the user is writing code but if he presses CTRL+S (auto-build enabled) or triggers a build manually, two threads - the compiler and the Java reconciler - start to parse, resolve, analyse code and build ASTs together. This process is wasteful as far as the Java reconciler is concerned. If the AST is all that it needs, perhaps the compiler can return it as it is to the reconciler. We should think of better strategies to remove this redundancy at compile time. Filing this bug initially in JDT/UI to get everyone's opinion. May be moved to JDT/Core if needed.
Good idea. The reconciler already tries to detect the 'save' delta and ignore it but obviously not good enough. In order to solve this bug we need a flag (combination) that uniquely identifies a save operation. It looks like this is mostly {CONTENT | FINE GRAINED | PRIMARY RESOURCE} but I'm not sure this directly maps to 'save'. Moving to JDT Core for a follow-up.
(In reply to comment #1) > Good idea. The reconciler already tries to detect the 'save' delta and ignore > it but obviously not good enough. In order to solve this bug we need a flag > (combination) that uniquely identifies a save operation. It looks like this is > mostly {CONTENT | FINE GRAINED | PRIMARY RESOURCE} but I'm not sure this > directly maps to 'save'. How will a flag in JDT/Core help the reconciler? Does the reconciler wait for any input from the compiler?
> How will a flag in JDT/Core help the reconciler? Does the reconciler wait for > any input from the compiler? The reconciler also handles deltas (e.g. to update problems when a related CU changed). If the delta is a 'save' on X then the reconciler for X can ignore that delta.
Btw, just for the sake of documentation, we should also check that we dont do the double operation in cases when there is a syntax error and the resource is just edited and not saved. I think the build operation keeps on getting triggered in such a case. For example, while debugging Parser.parse() for class Test { void f() { synchronized new Object(); } } I saw that even pressing a space starts the parsing in both reconciler and compiler threads. I don't know if the flag combination of such a scenario will be different from the save operation.
(In reply to comment #4) > I saw that even pressing a space starts the parsing in both reconciler and > compiler threads. I don't know if the flag combination of such a scenario will > be different from the save operation. Satyam showed that wasn't really the compiler and the reconciler but two reconcile operations. One was being triggered by the breadcumbs view. Again, this is strange. Can't the breadcrumbs view make use of the reconcile operation already happening?
> One was being triggered by the breadcumbs view. Again, > this is strange. Can't the breadcrumbs view make use of the reconcile operation already happening? The breadcrumb view doesn't trigger a reconcile.
Created attachment 193039 [details] call stack to show reconcilation by breadcrumbs See the attached callstack. Breadcumbs are surely in the picture here.
That is not directly related to the breadcrumb. It can happen at any time we need the model in reconciled state (but no AST is needed). See also bug 266299 and bug 265220.
Jay, can you please follow up on comment 1. Thanks!
