Java

Memory

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.

#!/bin/bash

# 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 <mogon-project>
#SBATCH --mem=1800M

module load lang/Java

export MALLOC_ARENA_MAX=4
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 .

CPU

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
export _JAVA_OPTIONS="-Djava.io.tmpdir/localscratch/${SLURM_JOB_ID}/"