To run Java on MOGON, you need to reserve much more memory than you think.

One example: Just calling java -version with a specified maximum heap size (1GB in this example), you need to reserve sufficient memory or Java will not be able to run correctly.


# for multithreaded JAVA programs it might(!) make sense to occupy a full node
#SBATCH -p short   # MOGON I
#SBATCH -p smp     # MOGON II
#SBATCH -A zdvhpc
#SBATCH --mem=1800M

module load lang/Java

srun  java -Xms1G -Xmx1G -version

Note that for larger heap sizes, you just need to keep the offset large enough. To use more CPUs, instruct your program accordingly and reserve them.

export MALLOC_ARENA_MAX=4 might be necessary to cope with the memory allocation in glibc arenas.


As Java creates additional threads for JVM maintainance (e.g. garbage collection) it is advisable to reserve an additional core for the Java overhead. I.e., if you have a single-threaded Java application, you should reserve a second CPU slot by using the -c 2 option in your submission script to sbatch.

Pointing JAVA applications to node local scratch directories

On our clusters all jobs are provided with a node local scratch directory: /localscratch/$SLURM_JOB_ID. If a particular application does not allow this directory to be supplied on the command line, yet requires to write scratch files, the _JAVA_OPTIONS allows to define the scratch directory anyway:

# put this in your job submission script to specify the local scratch directory