Saturday 3 May 2008

OutOfMemory error when using Findbugs plugin in Maven? Set the Maven heap size via MAVEN_OPTS

I was doing a "mvn site" and I got an OutOfMemory error at the stage
where it's using the Findbugs plugin:

[INFO] Generating "FindBugs Report" report.
[INFO] No effort provided, using default effort.
[INFO] Using FindBugs Version: 1.2.0
[INFO] No threshold provided, using default threshold.
[INFO] Debugging is Off
[INFO] No bug include filter.
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Java heap space
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.getUpdateableAvailableLoadMap(ValueNumberFrame.java:409)
at edu.umd.cs.findbugs.ba.vna.ValueNumberFrame.copyFrom(ValueNumberFrame.java:285)
at edu.umd.cs.findbugs.ba.FrameDataflowAnalysis.copy(FrameDataflowAnalysis.java:38)
at edu.umd.cs.findbugs.ba.vna.ValueNumberAnalysis.trans

After a bit of research, I set this variable to give enough memory to
Maven, and it fixed the problem. Obviously, change the Xmx value
depending on how much RAM you have to spare.

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:MaxPermSize=512m"

Other posts have mentioned that it's actually setting a MaxPermSize
higher than the default value (32m) that makes the difference. So
let's test it by just setting the first two values:

MAVEN_OPTS="-Xmx1024m -Xms128m"

Actually, it works!

INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 11 seconds


Other people have recommended setting the plugin property
"maven.findbugs.jvmargs" but I have not tried this out yet. Now in my
pom.xml, I currently have:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.1.1</version>
</plugin>

Which isn't actually the latest version anymore. Maybe the newest
version of the plugin - 1.2 has fixed it.. Let's change it to:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.2</version>
</plugin>

But this time, let's NOT have anything in MAVEN_OPTS. Let's see if the
newer version can do it with the default java settings. Now run mvn
site again.

(Long delay follows). Oh great, more jars to download. WTF? castor?
openejb? xstream? Hardly a build goes by where I don't get yet another
surprise download due to transitive dependencies. Am glad we have
Artifactory set up at work, so only one person has to suffer the
delays of downloading each new jar file.

No dice. OutOfMemoryError again. Let's set our heap to a smaller
figure, compared to before, see if that's enough.

MAVEN_OPTS="-Xmx256m -Xms128m"

Works!

I think this last one can be a safe starting value to use if you ever
run into the OutOfMemory error Findbugs from inside maven. I was
surprised to find out that the default heap is only 32m when JVM is in
client mode, and 64m when in server mode. See here:
http://www.unixville.com/~moazam/stories/2004/05/17/maxpermsizeAndHowItRelatesToTheOverallHeap.html

2 comments:

Antony Stubbs said...

Artifactory? You should check out Nexus. I made the switch a long time ago. Nexus is made by the same people who make maven.

krangsquared said...

There's actually two repository managers made by the people who make Maven. Nexus is from Sonatype, which has Jason Van Zyl, one of the Maven creators. But there's also Archiva, made by other people in the Maven project.

Anyway, yeah, Nexus rules! It keeps files on the filesystem instead of a database. Duh. (I never liked that aspect of Artifactory) Nicer, shinier interface as well.

Unfortunately, they've standardised on Artifactory at work after my section started using it. Oh well, at least I know which one to recommend next time.