JVM Options

On Unix machines JVM options are set via the BOOT_JVM_OPTIONS environment variable:

export BOOT_JVM_OPTIONS='-Xmx2g -client'

or in the local or global boot.properties:

BOOT_JVM_OPTIONS=-Xmx2g -client

Windows

If you're using the boot.exe executable for Windows you must create a boot.l4j.ini file containing your desired options as described in the launch4j documentation, placing it in the same directory as your boot.exe.

For further debug information, run boot --l4j-debug. Besides showing the boot help options, it will write launch4j.log in the directory where your boot.exe resides in the path.

For example in case you'd like to start boot for remote debugging on Windows, you can create this boot.l4j.ini:

-agentlib:jdwp=transport=dt_socket,address=localhost:5005,server=y,suspend=n
# -Xmx1024m 
# -Xms512m 
# -XX:MaxPermSize=600m

Faster Startup

You can cut down the initial startup time with these options:

-client -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Xverify:none

Per-project settings

At the heart of Boot's design is the single JVM principle. This provides obvious performance benefits, and at the same time doesn't preclude multiple Clojure runtimes (via classpath isolation). But this also means that the JVM options have to be set in the shell, and not in the build configuration file. However, you can easily mimick project-dependent JVM options by wrapping the boot executable.

#!/usr/bin/env bash
 
if [ -f .boot-jvm-options ]; then
  OPTS=`cat .boot-jvm-options`
fi
 
BOOT_JVM_OPTIONS="$OPTS" boot "$@"

More Heap Space

If you're running out of heap space you can add an option to increase the maximum heap space for the JVM:

-Xmx2g

PermGen Errors (Java 7)

Boot will start multiple Clojure runtimes in Pods. Each one will create a lot of classes, each of which will occupy space in the PermGen (Permanent Generation) of the JVM garbage collector. This means that this space will never be reclaimed when the pod falls out of scope. If you're getting PermGen allocation errors you can try adding these options:

-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

The -XX:MaxPermSize option was removed in Java 1.8, along with PermGen itself.

Metaspace grows large (Java 8)

What was PermGen in Java 7 (see above) is Metaspace in Java 8. Other than PermGen Java 8's Metaspace is not limited by default and will grow until it it's the systems actual memory limit. To prevent Metaspace from taking up significant memory you can limit the size of the Metaspace using -XX:MaxMetaspaceSize:

-XX:MaxMetaspaceSize=100m

Don't swallow stacktraces

The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow. StackOverflow

-XX:-OmitStackTraceInFastThrow

Micha's Setup

This is how I have my system configured.

OSX

$ uname -mrsv
Darwin 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

$ echo $BOOT_JVM_OPTIONS
-client -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Xmx2g -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -Xverify:none

Linux

$ uname -msrv
Linux 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64

$ java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

$ echo $BOOT_JVM_OPTIONS 
-Xmx2g -client -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -Xverify:none