User Tools

Site Tools


java

JAVA on Mogon

Memory

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

E.g. even for just calling java -version with a specified maximum heap size (1GB in this example), you need to sufficient memory or Java won't start.

#!/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 zdvhpc
#SBATCH -n 1
#SBATCH --mem=1800M
 
module load lang/Java
 
export MALLOC_ARENA_MAX=4
srun -n 1  java -Xms1G -Xmx1G -version

Note that for larger heap sizes, you just need to keep the offset large enough. Set -c x with x being the number of threads you want to instruct your program to use; it will be 1 by default.

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}/"
java.txt · Last modified: 2019/01/14 10:31 by meesters