Community
Participate
Working Groups
I have trying hard to weave some aspects into a system with ~1600 classes. Everytime I get this below exception. I tried setting -Xmx even to 1024 it is not working. Any comments please? Downloaded the AspectJ from: http://download.eclipse.org/tools/ajdt/34/update java.lang.OutOfMemoryError: Java heap space at java.nio.HeapByteBuffer.<init>(Unknown Source) at java.nio.ByteBuffer.allocate(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.forOutputStreamWriter(Unknown Source) at java.io.OutputStreamWriter.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at org.aspectj.weaver.bcel.LazyClassGen.toLongString(LazyClassGen.java:779) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1756) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1693) at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1458) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1272) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:371) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:358) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:977) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:265) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:179) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:311) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:183) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:88) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:223) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
How are you setting the Xmx value? on the eclipse startup? you could break the application into pieces and weave a piece at a time. However 1600 classes doesn't really seem that many so I'm surprised it is running out of memory. if you are currently in eclipse you can also try batch compiling on the command line or via Ant - to see if that makes a difference since it should consume much less memory.
Created attachment 137761 [details] Out of memory error - please see the attachment
Did you see my previous questions: > How are you setting the Xmx value? on the eclipse startup? Did you try building on the command line or from Ant - did you try weaving pieces of the application? How pervasive is your aspect - lots of advice? wildcarded pointcuts? Very vague pointcuts can cause excessive weaving and consume more memory than you need to.
(In reply to comment #3) > Did you see my previous questions: > > How are you setting the Xmx value? on the eclipse startup? > Did you try building on the command line or from Ant - did you try weaving > pieces of the application? > How pervasive is your aspect - lots of advice? wildcarded pointcuts? Very > vague pointcuts can cause excessive weaving and consume more memory than you > need to. Hi, I set -Xmx to 1024m in the eclipse.ini file. The out of memory still occurred. Then, I also tried setting -Xmx to 1024m in the aspectj compiler options through Eclipse GUI. I think the pointcuts are not vague. In fact, they most likely to match < 50 files or so out of my ~1600 classes. Downloaded the Aspectj1.6 and tried it on the command line outside of the Eclipse using the ajc compiler. The weaving worked without memory errors. Unfortunately, all the weaved classes are placed in one folder - not really matching the package structure of my original Java classes- So, it is hard for me to visualize the cross-cutting concerns. It would be great if you could tell me how I can force the ajc compiler to weave classes and follow the package structure. Then, I can make use of the Eclipse Aspect Visualizer right?
> I set -Xmx to 1024m in the eclipse.ini file. The out of memory still > occurred. Then, I also tried setting -Xmx to 1024m in the aspectj compiler > options through Eclipse GUI. setting it in the eclipse gui won't help due to the compilation not being run in a forked VM. I don't set it in eclipse.ini myself but that sounds reasonable - i usually set it via: eclipse -data myworkspace -vmargs -Xmx1024M > I think the pointcuts are not vague. In fact, they most likely to match < 50 > files or so out of my ~1600 classes. are you doing anything like matching on target/this/args with interface types - that can cause a huge overhead. > Downloaded the Aspectj1.6 and tried it on the command line outside of the > Eclipse using the ajc compiler. The weaving worked without memory errors. > Unfortunately, all the weaved classes are placed in one folder - not really > matching the package structure of my original Java classes- So, it is hard for > me to visualize the cross-cutting concerns. It would be great if you could tell > me how I can force the ajc compiler to weave classes and follow the package > structure. Then, I can make use of the Eclipse Aspect Visualizer right? compiling on the command line you just specify an output folder in order for it to produce correct structure based on package structure. ajc -d bin blah.java blah.aj etc When running in that mode the only support you have for understanding the weaving is using the '-showWeaveInfo' flag which will tell you what got woven where. It would be interesting to know if using that flag does just produce the 50 places you think it should.
Just tried it from the command line. There are ~770 Join points that matched the pointcuts. It would be great if AspectJ could be invoked from Eclipse without memory errors. I am curious how I can visualize those join points in the Eclipse "Aspect Visualization" perspective?
770 isn't all that many so I wonder why you are getting memory issues. Unfortunately the Aspect Visualization perspective works only if the code is built and woven inside eclipse. It would be interesting to know if AspectJ can build the code without any aspects applying - or if that still leads to the memory problem. Or another thing you can try is splitting the code up into a couple of pieces and weaving each separately. In order to properly debug where the memory is going in this situation, I would need the complete project.
I tried that actually. It was not easy to break the application because some of the packages have default visibility which produces compilation errors. I gave up the idea of breaking the application into pieces. > It would be interesting to know if AspectJ can build the code without any aspects applying - or if that still leads to the memory problem. Just converted my eclipse Java project into an AspectJ project. Unfortunately, out of memory error has occured even though there were no aspects to weave. FYI: Some of my packages have more ~150 classes. Is there anything I can do for you?
If you are able to share the code with me, I can profile where the memory is going - or you can do it (with yourkit or somesuch tool) and let me know where it has all gone? I'm suspecting the structure model created for AJDT.
Created attachment 138340 [details] This error occured when I converted my Java project into an AspectJ project
Created attachment 138342 [details] Stack Trace The out of memory error occured when I try to weave one aspect into my Java project.
Created attachment 138347 [details] Memory leak suspects Is there anything I can do for you?
unfortunately those suspects are not helpful :( I would expect those types to consume a ton of space. I'd be more interested in structure model related types. One thing you could try is this option in the AspectJ project properties section: -Xset:typeDemotion=true it is intended for load time weaving but may do something for compile time weaving - the interaction of this option with incremental compilation is currently 'undefined' though... after that, we are running low on options unless you are able to share the project with me.
(In reply to comment #13) > unfortunately those suspects are not helpful :( I would expect those types to > consume a ton of space. I'd be more interested in structure model related > types. > One thing you could try is this option in the AspectJ project properties > section: > -Xset:typeDemotion=true > it is intended for load time weaving but may do something for compile time > weaving - the interaction of this option with incremental compilation is > currently 'undefined' though... > after that, we are running low on options unless you are able to share the > project with me. Tried that -Xset. Unfortunately, got the out of memory error. The system is from NASA and it is impossible to send the code. sorry for that. We can probably try it on an open-source project. Do you anything specific on your mind?
I don't have an open source project in mind. I'm not sure what we can say though. AspectJ does consume more memory than standard javac - there is extra state to keep around in order for incremental compilation to work and for the relationships map (which drives the markers in the UI). I've successfully built spring framework in the past (the whole thing as one big src folder) and that was OK. Are you absolutely sure the memory setting is getting through OK to the UI? You have observed in the task manager (or mac/linux equivalent) that the eclipse is grabbing vast amounts of memory? it just seems odd that we only have one user having problems with memory on compilation right now.
(In reply to comment #15) > I don't have an open source project in mind. I'm not sure what we can say > though. AspectJ does consume more memory than standard javac - there is extra > state to keep around in order for incremental compilation to work and for the > relationships map (which drives the markers in the UI). > I've successfully built spring framework in the past (the whole thing as one > big src folder) and that was OK. > Are you absolutely sure the memory setting is getting through OK to the UI? > You have observed in the task manager (or mac/linux equivalent) that the > eclipse is grabbing vast amounts of memory? it just seems odd that we only > have one user having problems with memory on compilation right now. Andrew, > Are you absolutely sure the memory setting is getting through OK to the UI? How can I make sure this or how can I check this, could you please attach a screenshot showing how to configure the memory settings so that we are in the same page thanks Dharma
the only way I configure memory is from the command line eclipse -data myworkspace -vmargs -Xmx1024M If you are using eclipse.ini, I read that is supposed to do the same thing, but I don't know as I don't use it myself. If I were checking it I would attach yourkit profiler to eclipse and observe heap usage. Another option without yourkit is probably JConsole which should be able to show heap sizes if attached to the eclipse VM. Or the more crude measures are opening task manager and observing memory used by the eclipse.exe process, or probably something like 'top' on mac/linux. I'm merely interested if the memory goes up to around a gig before the failure occurs, indicating the memory setting is getting through.
Created attachment 138813 [details] Task manager data for AspectJ error analysis
surprised that shot only shows 400Meg usage - is that as high as it gets? Actually I just found a way to check the current config of eclipse. In the eclipse workspace go Help>AboutEclipseSDK. Click 'Configuration details' and check for the Xmx setting. Amongst mine it says: eclipse.vmargs=-Xmx1024M
Created attachment 138982 [details] Eclipse configuration
hmm, that suggests to me your Xmx is only 768M, rather than 1024M - can you increase it?
(In reply to comment #21) > hmm, that suggests to me your Xmx is only 768M, rather than 1024M - can you > increase it? Sorry I cannot increase - eclipse is not starting with 1024m, but as noted earlier, I tried it on a Win64 machine with 4048m. It still crashed.
why will eclipse not start with 1024M? That missing 256M may make the difference. You mentioned Win64 and 4048M but there must be something else wierd going on if it won't build in that much space - I've never tried such a large heap and don't know if eclipse will make use of it. I'm not really sure how to proceed - yes we use a lot of memory (much less than we used to but still a lot), but only you are reporting any issues. I am likely to look at memory consumption during 1.6.6 development but only with respect to weaving, and not compilation.
Created attachment 138984 [details] Eclipse configuration with 1024m
Created attachment 138985 [details] Error message
is it an out of memory exception when you click on details for the Update Markers job failure?
Created attachment 138986 [details] Error with details
open the eclipse error log (Window> Show view > error log) and see if you can more clearly find out what exception is behind that internal error
Created attachment 138987 [details] Stack Trace
hurray, finally we reach a bug and not a memory problem. stack is: AIOOBE 0 org.aspectj.asm.internal.NameConvertor.createShortName line 144, 205, 200, 145 It is related to one of the generics signatures you are using somewhere in your program ;) I need to know the problem signature before proceeding so the best I can do is put in some diagnostics that will come through in an AJDT shortly, then you can try that and tell me which signature it actually has a problem with. The code will catch the AIOOBE and print out the signature that led to it occurring.
(In reply to comment #30) > hurray, finally we reach a bug and not a memory problem. stack is: > AIOOBE 0 > org.aspectj.asm.internal.NameConvertor.createShortName line 144, 205, 200, 145 > It is related to one of the generics signatures you are using somewhere in your > program ;) > I need to know the problem signature before proceeding so the best I can do is > put in some diagnostics that will come through in an AJDT shortly, then you can > try that and tell me which signature it actually has a problem with. The code > will catch the AIOOBE and print out the signature that led to it occurring. Good. Do you mean I will get a version from you which spits out sort of log messages for testing? Do you have any specific generic pattern I should grep in my code base?
yes, there will be a new AJDT version you can upgrade to that contains the diagnostics and in the same place you currently see the ArrayIndexOutOfBounds you will instead see a more interesting message. I have no clue what kind of generic signature it will be so I can't get you to search unfortunately.
(In reply to comment #32) > yes, there will be a new AJDT version you can upgrade to that contains the > diagnostics and in the same place you currently see the ArrayIndexOutOfBounds > you will instead see a more interesting message. > I have no clue what kind of generic signature it will be so I can't get you to > search unfortunately. ok. good. Let me know when it is ready. I am looking forward to try it. Thanks.
The AJDT builds are currently failing but the next successful one will definetly include the diagnostics.
latest dev build of AJDT on 34 should include the diagnostics
Created attachment 139581 [details] Stack Trace on the latest AJDT dev. version Hi, Tried it on the latest version. Got a null pointer exception. Please see the screenshot
That is an AJDT stack trace, not an AspectJ one, so there may be more than one thing going wrong here. Is there anything else besides that error in your Error log view?
(In reply to comment #37) > That is an AJDT stack trace, not an AspectJ one, so there may be more than one > thing going wrong here. > Is there anything else besides that error in your Error log view? Unfortunately that is the only information available in the error log.
(In reply to comment #35) > latest dev build of AJDT on 34 should include the diagnostics Hi, I don't know where the diagnostic messages are stored. Please let me know if you need anything. I got nullPointerException as shown in the last attachment.
Hi, A new AJDT dev build is available now for 3.4. This should no longer throw the NPE that you were seeing. Can you please install this version and try again?
Created attachment 139885 [details] Error Message: Update site problem Hi, Sorry I could not get the latest update. Please see the attachment. Any comments?
Created attachment 139886 [details] Error Message: Update site problem Hi, Sorry I could not get the latest update. Please see the attachment. Any comments?
Looks like eclipse.org is all blocked up now because of the upcoming galileo release. You can try one of the mirrors: http://mirror.csclub.uwaterloo.ca/eclipse/tools/ajdt/34/dev/update/ http://mirror.cc.vt.edu/pub/eclipse/tools/ajdt/34/dev/update/
Created attachment 139924 [details] Screenshot of stack trace Hi, I just tried the latest version. Unfortunately, I am still getting the NullPointerException
Created attachment 139925 [details] Screenshot of stack trace Hi, I just tried the latest version. Unfortunately, I am still getting the NullPointerException
Created attachment 139926 [details] AJDT Event Trace
Arrrgh...sorry about that. Looks like the mirrors haven't been updated to the latest version of AJDT yet. Things are quite dicey on the eclipse.org servers at the moment because of the Galileo release. Here are some options: 1. wait a couple of days and try to update from the main ajdt dev servers 2. keep trying the main servers every so often and you might get lucky enough to be able to install AJDT. 3. install from a zip file. Here is the link to the zip file: http://www.eclipse.org/downloads/download.php?file=/tools/ajdt/34/dev/update/ajdt_2.0.0.e34x-20090622-2000_archive.zip And here are the instructions for manual install: http://wiki.eclipse.org/JDT_weaving_features#Manual_Install
Created attachment 140051 [details] Aspect tracing SQL Exception
Created attachment 140052 [details] Exception statck trace
Created attachment 140053 [details] Aspect Tracing JDBC Access
(In reply to comment #50) > Created an attachment (id=140053) [details] > Aspect Tracing JDBC Access Don't know whether you saw the attachment. Is there anything I can do?
(In reply to comment #51) > > Don't know whether you saw the attachment. Is there anything I can do? > I'm a little unsure what exactly the problem is now. Are you still having the out of memory errors? Is the concurrent modification exception occurring before or after the out of memory? Does the concurrent modification exception happen on every build? Only incremental? Only full? If only incremental, then is it happening when you edit the JDBC Access aspect that you attached?
(In reply to comment #52) > (In reply to comment #51) > > > > Don't know whether you saw the attachment. Is there anything I can do? > > > I'm a little unsure what exactly the problem is now. Are you still having the > out of memory errors? Is the concurrent modification exception occurring > before or after the out of memory? > Does the concurrent modification exception happen on every build? Only > incremental? Only full? If only incremental, then is it happening when you > edit the JDBC Access aspect that you attached? I don't see out of memory error now. However, I do get ConcurrentModificationException when I tried to weave those two aspects. I don't know what you meant by every build? Only > incremental? Only full?
I only see one aspect attached (this one: "Aspect Tracing JDBC Access") Can you attach the 2 aspects that are currently giving you problems? Please attach as text, not as an image so I can copy/paste into my workspace. This does appear to be a different problem than the one you saw originally. So, I may open a new bug report for it.
(In reply to comment #54) > I only see one aspect attached (this one: "Aspect Tracing JDBC Access") > Can you attach the 2 aspects that are currently giving you problems? Please > attach as text, not as an image so I can copy/paste into my workspace. This > does appear to be a different problem than the one you saw originally. So, I > may open a new bug report for it. (In reply to comment #54) > I only see one aspect attached (this one: "Aspect Tracing JDBC Access") > Can you attach the 2 aspects that are currently giving you problems? Please > attach as text, not as an image so I can copy/paste into my workspace. This > does appear to be a different problem than the one you saw originally. So, I > may open a new bug report for it. Hi, The other aspect is "Aspect Tracing SQL Exception"). It is in the attachment. Also, I copy-and-paste here both the aspects. public aspect SQL_Exception { public pointcut callToSqlException() : call(* java.sql.SQLException+.*(..)) || call(java.sql.SQLException..new(..)); before() : callToSqlException(){ } } public aspect JDBC_Driver { public pointcut callToJDBC() : call(* java.sql.DriverManager+.*(..)) || call(java.sql.DriverManager..new(..)); before() : callToJDBC(){ } }
I just raise Bug 281687. Please use that bug report to discuss the Concurrent<ModificationException you are seeing. I also committed some changes to AJDT so that the offending part of AJBuilder is now synchronized. This may address the problem you are seeing. Please read the bug and try out the new version when you can.
I am surprised there is no error log with diagnostics in for the patch I added for the AIOOBException (comment 32). However, it does look like we are passed the OutOfMemory problem. I guess we'll keep this bug open whilst working through bug 281687 - after that is resolved I might look to close this and open new bugs for other problems. Please, if you can, attach the textual stack traces rather than screenshots as they are easier to work with.
(In reply to comment #58) > I am surprised there is no error log with diagnostics in for the patch I added > for the AIOOBException (comment 32). However, it does look like we are passed > the OutOfMemory problem. I guess we'll keep this bug open whilst working > through bug 281687 - after that is resolved I might look to close this and open > new bugs for other problems. > Please, if you can, attach the textual stack traces rather than screenshots as > they are easier to work with. Sorry for any inconveniene with screenshots. Unfortunately, the OutOfMemory still exists. I tried it on the latest developement version. For the two aspects, things worked well. After that, I added one more aspect. Now, I get out of memory error. Here is the new aspect and the stack trace. public aspect JDBC_Driver { public pointcut callToJDBC() : call(* java.sql.DriverManager+.*(..)) || call(java.sql.DriverManager..new(..)); before() : callToJDBC(){ } } Message: Compile error: OutOfMemoryError thrown: Java heap space java.lang.OutOfMemoryError: Java heap space at java.nio.HeapByteBuffer.<init>(Unknown Source) at java.nio.ByteBuffer.allocate(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.forOutputStreamWriter(Unknown Source) at java.io.OutputStreamWriter.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at org.aspectj.weaver.bcel.LazyClassGen.toLongString(LazyClassGen.java:777) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1773) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1710) at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1472) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1286) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:371) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:358) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1003) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:267) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:181) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:313) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:185) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:88) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:245) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
as it is sometimes working and sometimes not - looks like you are right on the line with the memory required. Actually, the stack: Message: Compile error: OutOfMemoryError thrown: Java heap space java.lang.OutOfMemoryError: Java heap space at java.nio.HeapByteBuffer.<init>(Unknown Source) at java.nio.ByteBuffer.allocate(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.<init>(Unknown Source) at sun.nio.cs.StreamEncoder.forOutputStreamWriter(Unknown Source) at java.io.OutputStreamWriter.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at java.io.PrintStream.<init>(Unknown Source) at org.aspectj.weaver.bcel.LazyClassGen.toLongString(LazyClassGen.java:777) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1773) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1710) may suggest a 'crashing whilst crashing' problem and that there is a real problem trying to be reported but in building the support context around the message it is running out of memory. I might give you a patch for LazyClassGen to see if we can avoid building the context and print out the underlying issue.
Created attachment 140273 [details] Zip of replacement class files This replaces the LazyClassGen types in your weaver with a version that doesn't build as much message context. To apply, shutdown eclipse, locate the most recent org.aspectj.weaver plugin installed in your eclipse then in that directory // backup what you have copy aspectjweaver.jar aspectjweaver.jar.original // unpack and apply the patch jar -xvf weaver.zip jar -uvf aspectjweaver.jar org Now restart eclipse
(In reply to comment #62) > Created an attachment (id=140273) [details] > Zip of replacement class files > This replaces the LazyClassGen types in your weaver with a version that doesn't > build as much message context. > To apply, shutdown eclipse, locate the most recent org.aspectj.weaver plugin > installed in your eclipse then in that directory > // backup what you have > copy aspectjweaver.jar aspectjweaver.jar.original > // unpack and apply the patch > jar -xvf weaver.zip > jar -uvf aspectjweaver.jar org > Now restart eclipse I tried it and got two stack traces for you. Trace 1: java.lang.OutOfMemoryError: Java heap space at java.lang.AbstractStringBuilder.<init>(Unknown Source) at java.lang.StringBuffer.<init>(Unknown Source) at org.aspectj.weaver.bcel.LazyMethodGen$BodyPrinter.print(LazyMethodGen.java:674) at org.aspectj.weaver.bcel.LazyMethodGen$BodyPrinter.run(LazyMethodGen.java:598) at org.aspectj.weaver.bcel.LazyMethodGen.print(LazyMethodGen.java:559) at org.aspectj.weaver.bcel.LazyClassGen.printOne(LazyClassGen.java:827) at org.aspectj.weaver.bcel.LazyClassGen.print(LazyClassGen.java:789) at org.aspectj.weaver.bcel.LazyClassGen.toLongString(LazyClassGen.java:777) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1773) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java:1710) at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1472) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1286) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:435) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:371) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:358) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1003) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:267) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:181) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:105) at org.aspectj.ajde.core.AjCompiler.buildFresh(AjCompiler.java:97) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:243) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) --- Trace 2: ---- java.lang.OutOfMemoryError: Java heap space at org.eclipse.jdt.internal.compiler.parser.Scanner.getCurrentIdentifierSource(Scanner.java:428) at org.eclipse.jdt.internal.compiler.parser.Parser.pushIdentifier(Parser.java:9811) at org.eclipse.jdt.internal.compiler.parser.Parser.consumeToken(Parser.java:7361) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9236) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9598) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.parseStatements(MethodDeclaration.java:122) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.parseMethods(TypeDeclaration.java:802) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8513) at org.eclipse.jdt.internal.compiler.SourceElementParser.parseCompilationUnit(SourceElementParser.java:909) at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:68) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:72) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:354) at org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:692) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:394) at java.lang.Thread.run(Unknown Source)
Surprised to see: org.aspectj.weaver.bcel.LazyClassGen.toLongString(LazyClassGen.java:777) in the stack trace as the patch removed line 777. But the second trace indicates there is just not enough memory to build the code - I guess building this project will just have to wait until I have time to do a memory pass over the data structures.
For 1.6.6 look to do a quick memory profile of AJDT to see if there are anything unexpected in terms of memory usage for a large project.
(In reply to comment #65) > For 1.6.6 look to do a quick memory profile of AJDT to see if there are > anything unexpected in terms of memory usage for a large project. > ok, thanks for the info.
I'm testing the shadows compiler project as the only decent example of a large AJ project that I have access to. The memory is going where you would imagine, after a build of this project the compiler state object is 90Meg whilst the structure model is 51Meg. This latter object has grown over recent releases because of the handles becoming rather longer than they used to be. For each ProgramElement there is a handle and there are 40000ish program elements in this project. The relationship map part of the structure model is only 3Meg, the memory is all in the actual structure model. Choosing a big ProgramElement as an example, the one for the type 'ProblemReporter' (which is a java type with a *lot* of methods) is 850k on its own. I can see two options for making a dent in this. - don't keep hold of handles at a particular level, for example 'below the type level' and compute them when required. - support an interning mechanism for the component parts of these handles (which could also be used by the join point names and make them smaller). This latter option could make a huge difference to the model size. For example here is a typical handle: "=shadows.org.eclipse.jdt.core/compiler<org.aspectj.org.eclipse.jdt.internal.compiler.problem{ProblemReporter.java[ProblemReporter~incompatibleExceptionInThrowsClause~QSourceTypeBinding;~QMethodBinding;~QMethodBinding;~QReferenceBinding;" All handles for a project would be duplicating '=shadows.org.eclipse.jdt.core/' All files in the same source folder duplicating '=shadows.org.eclipse.jdt.core/compiler' All entries in the same type would be duplicating '=shadows.org.eclipse.jdt.core/compiler<org.aspectj.org.eclipse.jdt.internal.compiler.problem{ProblemReporter.java[ProblemReporter'. And in that final case (as an example) the ProblemReporter ProgramElement has 452 children where all the handles share that prefix.
(In reply to comment #67) > I'm testing the shadows compiler project as the only decent example of a large > AJ project that I have access to. The memory is going where you would imagine, > after a build of this project the compiler state object is 90Meg whilst the > structure model is 51Meg. This latter object has grown over recent releases > because of the handles becoming rather longer than they used to be. For each > ProgramElement there is a handle and there are 40000ish program elements in > this project. > The relationship map part of the structure model is only 3Meg, the memory is > all in the actual structure model. > Choosing a big ProgramElement as an example, the one for the type > 'ProblemReporter' (which is a java type with a *lot* of methods) is 850k on its > own. > I can see two options for making a dent in this. > - don't keep hold of handles at a particular level, for example 'below the type > level' and compute them when required. > - support an interning mechanism for the component parts of these handles > (which could also be used by the join point names and make them smaller). > This latter option could make a huge difference to the model size. > For example here is a typical handle: > "=shadows.org.eclipse.jdt.core/compiler<org.aspectj.org.eclipse.jdt.internal.compiler.problem{ProblemReporter.java[ProblemReporter~incompatibleExceptionInThrowsClause~QSourceTypeBinding;~QMethodBinding;~QMethodBinding;~QReferenceBinding;" > All handles for a project would be duplicating '=shadows.org.eclipse.jdt.core/' > All files in the same source folder duplicating > '=shadows.org.eclipse.jdt.core/compiler' > All entries in the same type would be duplicating > '=shadows.org.eclipse.jdt.core/compiler<org.aspectj.org.eclipse.jdt.internal.compiler.problem{ProblemReporter.java[ProblemReporter'. > And in that final case (as an example) the ProblemReporter ProgramElement has > 452 children where all the handles share that prefix. Hi, Any breakthroughs just curious to know.
We have an approach that will fix this for good - removing all structure nodes that represent class files and only keeping those that represent aspects. However, I don't know what the outlook is on that work being completed. In the short term I tried something basic to try and avoid too much duplication on the handles but it didn't recover as much as I had hoped.
I will try and get a patch out shortly that will attempt to address memory issues. If I can turn off handle caching, that will save a ton of memory but at the cost of performance as they are not so cheap to calculate. However, it is worth a shot to see if it helps address the problem reported here.
(In reply to comment #70) > I will try and get a patch out shortly that will attempt to address memory > issues. If I can turn off handle caching, that will save a ton of memory but > at the cost of performance as they are not so cheap to calculate. However, it > is worth a shot to see if it helps address the problem reported here. > Thanks for the info. Looking forward to trying your patch.
Created attachment 143923 [details] replacement classes The attached jar contains a few replacement classes which remove handle caching for program elements. To apply the patch, go to the org.aspectj.weaver_* plugin in your eclipse plugins directory (whichever plugin is the latest version by date) then: copy aspectjweaver.jar aspectjweaver.jar.original jar -xvf patch_278496.jar jar -uvf aspectjweaver.jar org Building my sample project - around a 1000 classes with quite a bit of crosscutting, the heap usage went from 200M to 180M, so about 10%. There are further options for saving memory but this is the first thing to try.
(In reply to comment #72) > Created an attachment (id=143923) [details] > replacement classes > The attached jar contains a few replacement classes which remove handle caching > for program elements. > To apply the patch, go to the org.aspectj.weaver_* plugin in your eclipse > plugins directory (whichever plugin is the latest version by date) then: > copy aspectjweaver.jar aspectjweaver.jar.original > jar -xvf patch_278496.jar > jar -uvf aspectjweaver.jar org > Building my sample project - around a 1000 classes with quite a bit of > crosscutting, the heap usage went from 200M to 180M, so about 10%. > There are further options for saving memory but this is the first thing to try. Hi, I tried the patch, and get the following stack trace; org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.OutOfMemoryError: Java heap space) at org.eclipse.swt.SWT.error(SWT.java:3777) at org.eclipse.swt.SWT.error(SWT.java:3695) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open(InternalErrorDialog.java:80) at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.openQuestionDialog(IDEWorkbenchErrorHandler.java:184) at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.handleException(IDEWorkbenchErrorHandler.java:139) at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.access$0(IDEWorkbenchErrorHandler.java:131) at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler$1.runInUIThread(IDEWorkbenchErrorHandler.java:106) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ajdt.internal.ui.dialogs.MessageDialogWithToggle.openQuestion(MessageDialogWithToggle.java:294) at org.eclipse.ajdt.internal.utils.AJDTUtils.confirmAutoRemoveImport(AJDTUtils.java:976) at org.eclipse.ajdt.internal.utils.AJDTUtils.removeAspectJNature(AJDTUtils.java:661) at org.eclipse.ajdt.ui.AspectJUIPlugin.convertFromAspectJProject(AspectJUIPlugin.java:173) at org.eclipse.ajdt.internal.ui.actions.RemoveAJNatureAction.run(RemoveAJNatureAction.java:51) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3823) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3422) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2384) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2348) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2200) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:495) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:490) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) Caused by: java.lang.OutOfMemoryError: Java heap space
i guess you need to save even more memory then - the next change in that direction will take me longer to implement.
Created attachment 144420 [details] Patch for asm module patch covering work so far on non-caching handles and basics of an interning mechanism. putting it here so I can go back to HEAD and work on something else.
Created attachment 144756 [details] Replacement BcelWeaver This is a replacement for some other classes in the aspectjweaver plugin - apply in the same way as before. It shouldn't clash with the existing patch you may still have applied - feel free to use them together or this one alone. This is a step towards what I'd like to commit as a real solution. What we do here is after weaving each file we see if it has any relationships (either incoming or outgoing). If it has none (and it isn't an aspect) then we delete it from the model. It should be the case that should it ever be needed in the model it will be recreated at that time. My model reduction here was 50% in my case, from 33Meg to 16Meg. The earlier patch for handle caching reduces it down further to just 11Meg. Obviously the benefits of this patch will depend on how crosscutting your aspect is. If you have an aspect that touches every single file - it won't provide any benefit at all.
any luck trying that patch?
(In reply to comment #77) > any luck trying that patch? Hi, I tried but no luck for me. I still get an out of memory error.
really surprised that made no difference to you unless the aspects are advising a very high proportion of classes. oh well, back to the drawing board.
me again... The latest AJDT builds for Eclipse 3.5 include AspectJ 1.6.7 - this does a much reduced type analysis for determining pointcut matches. It may enable you to compile.
have you had a chance to try a recent AJDT?
removing target whilst waiting on feedback
Revisiting this for 1.6.10. Reactivated the prototype but it missing some key enhancements. The biggest missing piece is that if the type is the only child of a compilation unit and it is removed, the parent compilationunit can also be removed - this will remove all the import references being needlessly held onto. There are some maps to be tidied up too (caches for fast access to pieces of the model).
first set of changes are in for model reduction. They are in the latest AJDT for both 3.5 and 3.6. Due to it being experimental, need to turn it on with -Xset:minimalModel=true in project properties. Building 'shadows' as an example project, it saves around 50Meg of heap. Following on from this there is type demotion to explore. This is more complex but I do think we can do something.
I'm testing now and I found at least one problem with the model reduction. This has to do with static inner aspects. It seems that classes with static inner aspects are dropped from the model even though they contain aspects. I'm attaching a failing project. Strangely, this causes one of the AJDT core tests to fail, but I can't reproduce the failure in a workspace. However, I can see that the class is being removed when it shouldn't.
Created attachment 174893 [details] failing project This project has a static inner aspect. It is removed from the model when it shouldn't be.
good catch. Fixed.
All UI tests are passing locally. I am getting more confident with these changes.
test coverage progressing for new world demotion algorithm, looks like it is going to work. As with model deletion, this will require an option to be enabled whilst we test it out in the field, likely to be the typeDemotion=true option.
world demotion changes are IN. Next dev build of AJDT should include the changes. To turn on all optimizations, the project needs configuring with: -Xset:minimalModel=true,typeDemotion=true This is experimental function for now but if I can get feedback on it and iron out any issues, I'll make it the default in 1.6.10. System properties can also be set to turn these things on aspectj.minimalModel=true aspectj.typeDemotion=true when activated, the options will print messages to sysout indicating they are ON.
feedback from Emond on the mailing list: =================== Hi, I've tried the new dev build with these options. These are the results: On Friday 06 August 2010 00:56:18 Andy Clement wrote: > Under bug 278496 I've gradually been working on this, the idea is to > reduce the memory used for compile-time weaving in AJDT, using > something similar to the strategy I used to reduce memory for Loadtime > weaving. > > Then work as normal. I'm interested in whether: > - you see a noticeable reduction in heap usage (maybe turn on the > eclipse heap status monitor under Window>Preferences>General) Memory usage is down a bit (I'd say about 20%, compared to just minimalModel=true). The largest AjState object went down from 250M to just under 200M. Eclipse now takes just over 700M after a full GC, compared to 850M without type demotion. > - you see a change in performance. With the more eager eviction model > these options employ, there may be more messing around to compile > stuff (probably only noticeable on full builds) The build seems a bit slower, but not much. It's still fast enough. > - it breaks ! Yes, it breaks a lot unfortunately. I had to click away about 70 errors. They all seem to be caused by a stack overflow: at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:430) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:430) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399) etc. Unfortunately, I can't dive into this deeper now and won't have time to test this the next couple of weeks, but I'll check back on this in september. Good luck with this, it seems you're on the right path. With these options disabled, memory usage goes up by 500M! =================== stackoverflow looks to be a new manifestation of the https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908 which is related to recovering things after discarding them and accidentally putting generic types into the type map (when the raw type should go in, with a reference to the generic type)
although I can't directly create the stackoverflow, I've been working on an assertion that will fire on the condition that leads to the overflow. If an attempt is made to put a generic type into the typemap, it fires. Armed with that I recreated a scenario that caused an attempt to put a generic type in there. Similar to the fix for the bug I mentioned, I now use that code again to recognize generics and convert them to their raw rep before storing. This fixes the problem I've seen, but we'll need to create an AJDT with the fix in to see what it does for Emond.
next dev builds of AJDT will contain the potential fix.
(In reply to comment #93) > next dev builds of AJDT will contain the potential fix. With build 2.1.1.e36x-20100817-1900, I still get the same stack overflow. I'll try to construct a testcase later today.
please update your AJDT again, that build you mention doesn't include yet another small fix I put in late last week.
Created attachment 177807 [details] Workspace that triggers a StackOverflow (In reply to comment #95) > please update your AJDT again, that build you mention doesn't include yet > another small fix I put in late last week. There seems to be no newer version available on http://download.eclipse.org/tools/ajdt/36/dev/update/ . I've attached a small workspace that triggers the bug. You need to set -Xms and -Xmx very low (I've set them to 128m) and rebuild several times, but here it crashes in about 1 out of 2 attempts.
unfortunately that workspace seems to contain a unconfigured project when I unpack it, the .project is 'empty' of configuration and there is no .classpath file. The AJDT build is now out (dated yesterday) that contains the most recent additional fix for the stackoverflow, please try it out.
My fault, I should have explained. The workspace contains 3 projects, 1 root project and 2 sub-projects, in common and webcomponents. You need to import them one-by-one (or use the workspace as a whole). However, I don't think it is needed anymore, because I can't reproduce the problem anymore with the latest version. I'll retry with a full workspace tomorrow to see if the problem is indeed fixed.
Any updates on this? I have a workspace with 5 AJ projects. Most of my classes have a pointcut that inserts a static initializer block to log something, and I'm getting out of memory errors quite a bit. Once I added the 5th AJ projects I had to increase my heap to 2.5GB just to stop the crashing. I added the system options described above but don't see the info in the AJDT console to indicate they were picked up. I'm using the most recent build from the eclipse update site-- are they included there? Thanks!
Hi Steve, I presume you are setting -Xset:minimalModel=true in the project properties. There is no message that will come out if you do things that way. If you set it via a system property prior to starting eclipse (aspectj.minimalModel=true) and run with the option -consolelog you will see this in the log output if it is picked up: ASPECTJ: aspectj.minimalModel=true: minimal model switched ON Another way to check if it is doing anything for you is in the AJDT event view. If you press the 'Prints the crosscutting model' button it will print the model it is storing in memory. If the option is working that output should not have entries in for types that are not affected by weaving. That may in fact be the problem facing you. If you are impacting a lot of files with just one bit of advice, we will currently continue to store those files in memory. minimalModel will only discard structure for files that are not advised. The next step in shrinking the model might be to discard the pieces of the file that are not advised in any way, leaving behind only the endpoints of the advises/advisedBy relationships. Can you see a reduction in memory used if you turn on the heap status monitor (General preferences > Show Heap Status). Hopefully if you do a full build without the option, then a full build with the option, you should see some kind of reduction? 2.5G sounds massive, are these really very large projects? With the option on, can you perhaps modify the pointcuts to advise far fewer places, and see if it does make a big difference to the heap used?
Thanks for the reply! I set it in the eclipse.ini as: -Daspectj.minimalModel=true -Daspectj.typeDemotion=true I set the consoleLog as well, but do not see any messages with ASPECTJ in them at all. I open the AJDT console but cannot seem to locate the button to which you referred to check the output. It's not that big of a workspace. I have 5 AJ projects probably less than 1500 classes total. I did comment out the aspect that was being weaved everywhere but it didn't make a _massive_ difference. Some difference yes, but not massive. I have a heap dump but its 1.5GB so I don't know how helpful that will be :-) Here are the top few lines from the heap histogram: 1: 5584660 433883280 [C 2: 5594745 223789800 java.lang.String 3: 4748651 151956832 org.aspectj.apache.bcel.classfile.ConstantUtf8 4: 1592718 126719128 [B 5: 66403 70377120 [Lorg.aspectj.apache.bcel.classfile.Constant; 6: 621562 64642448 org.aspectj.apache.bcel.classfile.Method 7: 228528 44468552 [Ljava.util.HashMap$Entry; 8: 1171023 42869176 [Lorg.aspectj.apache.bcel.classfile.Attribute; 9: 563491 40571352 org.aspectj.apache.bcel.classfile.Code 10: 1261944 40382208 org.aspectj.apache.bcel.classfile.ConstantNameAndType 11: 399802 38854792 [Ljava.lang.Object; 12: 185072 31473264 <constMethodKlass> 13: 946646 30292672 org.aspectj.apache.bcel.classfile.ConstantMethodref 14: 455154 29129856 org.aspectj.apache.bcel.classfile.LineNumberTable 15: 422438 27036032 org.aspectj.apache.bcel.classfile.LocalVariableTable 16: 17061 23584184 <constantPoolKlass> 17: 233864 22450944 org.aspectj.apache.bcel.classfile.Field 18: 185072 22249104 <methodKlass> 19: 651407 20845024 org.aspectj.apache.bcel.classfile.ConstantClass 20: 71518 18308608 org.aspectj.weaver.ReferenceType 21: 66781 18164432 org.aspectj.weaver.bcel.BcelObjectType 22: 297802 17061936 <symbolKlass> 23: 17061 14482592 <instanceKlassKlass> 24: 225776 14449664 java.util.HashMap 25: 290739 13955472 java.lang.ref.WeakReference 26: 14481 13875232 <constantPoolCacheKlass> 27: 285064 13683072 java.util.HashMap$Entry 28: 334062 13362480 java.util.ArrayList 29: 402627 12884064 org.aspectj.apache.bcel.classfile.ConstantString 30: 143846 12658448 org.eclipse.core.internal.resources.ResourceInfo 31: 66392 11153856 org.aspectj.apache.bcel.classfile.JavaClass 32: 214117 8690376 [I 33: 265841 8506912 org.aspectj.apache.bcel.classfile.ConstantFieldref 34: 146963 8229928 org.aspectj.apache.bcel.classfile.ExceptionTable I haven't loaded up the heap in a memory analyzer. I could be unfairly blaming ADJT I just haven't had such a large heap and as soon as I marked the fifth project as an AspectJ project is when I started getting the OOME and had to up the heap to 2.5 from 2.0GB Thanks so much for your consideration.
I do recall some race condition with those print statements actually, where I sometimes didn't see the "ASPECTJ:..." messages on eclipse starts. The quickest way for you to tell if minimalModel is on is by creating a little project with these three types in: A.java public aspect A { before(): staticinitialization(C) { } } C.java public class C { } D.java public class D { } After building it, open the ajdt event trace view and press the printmodel button. The output should look like this: 13:4:24 Hierarchy: =AAP/src =AAP/src< =AAP/src<*A.aj =AAP/src<*A.aj# =AAP/src<*A.aj'A =AAP/src<*A.aj'A&before =AAP/src<{C.java =AAP/src<{C.java# =AAP/src<{C.java[C Relationship map: =AAP/src<{C.java[C :: =AAP/src<{C.java[C --advised by--> [=AAP/src<*A.aj'A&before] =AAP/src<*A.aj'A&before :: =AAP/src<*A.aj'A&before --advises--> [=AAP/src<{C.java[C] Notice there is no entry for D.java, only for C.java, and that is because D is not advised. If you attempt the above and see an entry for D.java then the options are not set. Did you try the printmodel button after your builds, with and without the option set? The 'hierarchy' is where loads of memory gets used. With your aspect commented out you should see quite a large reduction. And of course if the option is working we shouldn't see any entries for files that are not advised. (I haven't talked much about typeDemotion as I usually find minimalModel is what really recovers the memory) Seems strange that projects of the sizes you are describing would need a 2.5G heap. The memory hogging classes you've indicated are the usual culprits for an AspectJ compile.
(In reply to comment #102) I verified that "D" is not in the model, and thus the minimalModel should be taking effect. I also browsed through the other models and they seem reasonable. I also am very confused why I need so much memory. I did run the eclipse memory analyzer and confirmed that more than 2GB of my heap was being retained by something in the org.aspectj.* although that may not really be a fair measure. I was just concerned another plugin was biting me. I see a correlation between adding a new project and lots of increased memory usage. In fact, when I first tried your exercise with A, C, D -- i just added a simple "TestADJTProject" enabled it for AspectJ support, and couldn't even do a full build without getting an OOME. My workspace has 5 aspectJ projects, and that made it six and that killed it. I got rid of the "version" aspect that I was using that was injecting itself into every class and that helped but its still huge. I am using about four aspects for transaction demarcation, logging, and some ITD stuff. I've attached the model output to see if you think that a model of this size should take up this much memory. Does the model support the incremental compiling? Or just the navigation features in JDT? Is there anyway I can still have integrated weaving in eclipse via incremental compilation without this model overhead? I tried turning off the JDT Weaving service but that didn't make a difference. Thanks so much for your help!
> I've attached the model output to see if you think that a model of this size should > take up this much memory. I can't see the attachment? If its too big to attach, feel free to email it to me (andrew.clement AT gmail.com)
Andy- the options you had me set: -Daspectj.minimalModel=true -Daspectj.typeDemotion=true with the changes that you pushed helped tremendously. You mentioned in an email that eventually you thought these -D options would be defaults. Were these defaults included in the last AJDT release? Or is this still an opportunity for the future.
funny you should mention that. Just last week I made them the default in AspectJ builds and the AJDT dev builds that were pushed out for STS 2.8.0 (I wrote a small section in the STS new and noteworthy about it: http://download.springsource.com/release/STS/doc/STS-new_and_noteworthy-2.8.0.M1.pdf ). So, grab a dev build and try it out. They will be default in the 2.2 AJDT release which isn't too far off.
unsetting the target field which is currently set for something already released
