Heap space issue

[Google Code Exporter]

I currently am running findbugs 1.3.9, and am running into a heap space issue. 
This I do not believe is any ordinary heap space issue. Like other heap space 
issues, you can simply increase the heap space through the Xmx arg, the only 
problem is I have -Xmx2500M which is I believe too much. I am also running 
findbugs on effort=max. Which I know consumes more memory, but I don't believe 
it needs this much memory. The .jar I'm scanning is 15MB if that is significant.

Here is a sample output:

     [exec]  [findbugs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
     [exec]  [findbugs]     at java.util.ArrayList.<init>(ArrayList.java:112)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.Frame.<init>(Frame.java:110)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.<init>(ValueNumberFrame.java:58)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.createFact(ValueNumberAnalysis.java:148)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.getFactAfterLocation(ValueNumberAnalysis.java:272)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.transferInstruction(ValueNumberAnalysis.java:174)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.transferInstruction(ValueNumberAnalysis.java:55)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.AbstractDataflowAnalysis.transfer(AbstractDataflowAnalysis.java:117)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.Dataflow.execute(Dataflow.java:356)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.classfile.engine.bcel.ValueNumberDataflowFactory.analyze(ValueNumberDataflowFactory.java:72)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.classfile.engine.bcel.ValueNumberDataflowFactory.analyze(ValueNumberDataflowFactory.java:47)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.classfile.impl.AnalysisCache.analyzeMethod(AnalysisCache.java:331)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getMethodAnalysis(AnalysisCache.java:281)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.ClassContext.getMethodAnalysis(ClassContext.java:937)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.ba.ClassContext.getValueNumberDataflow(ClassContext.java:356)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.detect.FindSelfComparison2.analyzeMethod(FindSelfComparison2.java:89)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.detect.FindSelfComparison2.visitClassContext(FindSelfComparison2.java:72)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.DetectorToDetector2Adapter.visitClass(DetectorToDetector2Adapter.java:68)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.FindBugs2.analyzeApplication(FindBugs2.java:971)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:323)
     [exec]  [findbugs]     at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1049)
     [exec]  [findbugs] Java Result: 1

Original issue reported on code.google.com by [e-mail] on 14 Mar 2011 at 8:50

[Google Code Exporter]

Would it help if we also reduced the size of the classpath. Currently we are 
including 156 jars which might cause a few of the issues.

Original comment by [e-mail] on 14 Mar 2011 at 9:02

[Google Code Exporter]

Just try tuning off effort=max. We've put a lot of work into tuning the normal 
effort so that it finds almost all of the errors you find using effort=max, and 
we haven't put a lot of work into tuning the time and space requirements for 
max.

Reducing the number of classes on the classpath might help. There isn't a lot 
we can do without access to the files you are analyzing. Is it an open source 
project?

Original comment by [e-mail] on 14 Mar 2011 at 9:13

• Changed state: NeedInfo

[Google Code Exporter]

Unfortunately I work for a company, so the code is not open source. A coworker 
found an instance where findbugs was not catching a proper close resource bug. 
I then read more about the effort variable. I can provide you with any kind of 
debugging information, but no source code. I have 2 exams on Thursday, but I 
would be free over spring break to examine the findbugs source code to see 
where is the issue occurring. I was wondering though, if I wanted to 
contribute, how would I go about contributing through google code. 

On a side note, I was wondering if a new rule can be created because I found an 
annoying issue that I see occurring a lot in code. I noticed that in junit test 
code, for an assert method, they usually do assert(expected, actual) instead of 
assert(actual, expected) and was wondering if a very low priority rule can be 
created for this kind of instance.

Thanks again for all your help!

Original comment by [e-mail] on 16 Mar 2011 at 8:07

[Google Code Exporter]

Sorry, for the side note, I meant to say instead of doing 
assertEquals(expected, actual) they do assertEquals(actual, expected)

Original comment by [e-mail] on 16 Mar 2011 at 8:14

[Google Code Exporter]

I actually fixed it now by splitting up the jar into two separate files and 
running both, one after the other. It found one more violation which is good. 
Thanks again for your help.

Original comment by [e-mail] on 23 Mar 2011 at 9:24

[Google Code Exporter]

Original comment by iloveeclipse on 23 Nov 2011 at 10:01

• Changed state: WontFix