Community
Participate
Working Groups
I am using the Eclipse 2.1 with aspectj 1.1.2 and the AJDT 1.1.2 plug-in and all the classes that are affected by an aspect, I get the following error: The type MyClass is already defined MyClass.java I do not have any other source files that declare a type called MyClass, nor do I have duplicate definitions of MyClass.java. I can take this same source tree and compile it successfully via ANT. I did not enable incremental compilation. For our project, I have over 1400 classes that are involved and need to run through the aspectj compiler. During our ANT process this takes at least 5 minutes to run. In order to even get Eclipse (AJDT) to compile this I had to increase the memory to 384MB. I just re-created the project and re-compiled my code I get the same error. For more details you can look at the following email trail in the newsgroups: http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00331.html
The long-term solution is to integrate more closely into the JDT structure model. For now, we can add an AJDT option that prevented the structure model from being built. This way you could control the memory tradeoff between seeing the structure info and minimizing memory use. You’d still get better compile performance, memory use, and integration than from launching an ant task.
Perhaps avoid building the structure model if the structure model pane is not displayed, and suggest that as the workaround.
I looked at structure models for projects with 1000+ classes and they were under 1MB. So the bytecodes that we keep in memory dominate the structure model, so generating the structure model introduces relatively little overhead. I will keep this bug open as an enhancements so that it prompts us to do more profiling of memory usage, etc.
Also, we should get the behavior that you asked for once the model is integrated with the JDT. When the Outline view is not around it won't be eagerly parsed, so it won't be in memory. However, I believe that we will still need to keep all the crosscutting relationships around from the last compile, at least until we have a "fast match" implementation that can do everything eagerly.
Mik, one additional comment that may help lead to a solution. I am in the process of upgrading from version 1.06 to 1.1 and I tried replacing the javac compile with ajc. When I did this my compile time went from 1 minutewith javac to 10 minutes with ajc. The interesting thing about this find leads me to believe that there is something more fundamentally going wrong when you deal with large projects. By the way our project is now up over 1500+ classes making the problem even worse.
Although Mik comments that the structure model is not particularly large, for much of the model we create Eclipse markers (for gutter annotations) and they will also be taking up space. just a thought.
Andy: regarding your comment #6, it occurrs to me that our use of markers can be a problem on large projects. Consider the fact that the JDT doesn't use Marker, but a much slimmer ConcreteMarker for problems list items. Markers aren't our model, the ASM is, so why don't we just generate markers eagerly for the current file, and discard them once the current file is no longer selected? Note that this would have to happen whenever an editor becomes active, not just when it's opened (so it might use an IPageListener or an ISelectionListener).
Note that markers are only created when an editor is opened or given focus or given a new file as input, or on a rebuild (for the current editor only). For this reason and following some investigations I felt that markers were unlikely to be causing any serious memory problems, however I have submitted a patch that will be included in 1.1.12, which deletes markers on closing of an editor window or when an editor is given a new file as input.
Marker model changed - see bug 78378: https://bugs.eclipse.org/bugs/show_bug.cgi?id=78378#c3
The AJDT issues in this area have been addressed. The biggest memory issue is currently in the compiler, which is covered under bug 44215. *** This bug has been marked as a duplicate of 44215 ***
