Java

Overview

Please read the following information carefully if running java applications on the CSF, whether they be your own code or 3rd-party applications. This is to ensure you use the correct number of threads when running java.

Java Runtime Environment Versions 1.6.0, 1.7.0 and 1.8.0 are installed on the CSF.

Restrictions on use

There are no licensing restrictions to running this software. Please note that Java (and the Java compiler) will not run on the login node due to memory restrictions on that node. Please see our Java compilation notes for more information on compiling Java code.

Set up procedure

The default is 1.7.0. It is not strictly necessary to load a modulefile for this version, but you can if you wish:

module load tools/java/1.7.0

1.6.0 and 1.8.0 are also available:

module load tools/java/1.6.0
module load tools/java/1.8.0

Running the application

Java will not run on the login node and you will receive the following error if you try to run java there:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

Jobs should be submitted to the compute nodes via batch. Note that Java may use several cores for garbage collection unless explicitly instructed not to. See below for how to run serial java code correctly.

Serial batch job submission

You must restrict the number of threads used by the java garbage collector otherwise it will attempt to use all of the cores in a node. If you are submitting a serial job then you will be using cores which have not been assigned to your job and will be trampling on other users’ jobs. Please add the following flags to your java command line:

-XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1

Java may also try to use more than one core’s share of the memory in a node. Add the following flag to your java command line to restrict memory usage to 4GB for example (if using a single core on an Intel 64GB compute node). For other nodes, please check the available memory per core and specify that number.

-Xmx4G              # 4G tells Java it can use 4 GB of RAM

For example, the following jobscript will run a serial java program safely:

#!/bin/bash
#$ -S /bin/bash
#$ -cwd                 # Job runs in current directory - where submitted from
#$ -V                   # Job inherits current environment

java -XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1 -Xmx4G my_app_class arg1

# If you have a .jar file:
java -XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1 -Xmx4G -jar myapp.jar arg1

Submit the jobscript using:

qsub scriptname

where scriptname is the name of your jobscript.

Parallel batch job submission

If your application uses Java Threads for parallelism then you should submit the job to the smp.pe parallel environment and request an appropriate number of cores.

Note that some Java code will use as many threads as possible and there is no way to restrict the number of threads (there is no equivalent of OMP_NUM_THREADS in Java). Hence you should submit a 12-core or 16 core parallel job (if running on Intel nodes) as per the examples below. This ensures you will have the entire node to yourself and so do not need to restrict the garbage collection threads or heap size. For example:

12 core job – westmere compute node

#!/bin/bash
#$ -S /bin/bash
#$ -cwd                 # Job runs in current directory - where submitted from
#$ -V                   # Job inherits current environment
#$ -pe smp.pe 12        # Run on all cores on an Intel node
#$ -l westmere          # Run on a westmere Intel node

java my_parallel_app_class arg1

12 core job – sandybridge compute node

#!/bin/bash
#$ -S /bin/bash
#$ -cwd                 # Job runs in current directory - where submitted from
#$ -V                   # Job inherits current environment
#$ -pe smp.pe 12        # Run on all cores on an Intel node
#$ -l sandybridge       # Run on a sandybridge Intel node

java my_parallel_app_class arg1

16 core job – ivybridge compute node

#!/bin/bash
#$ -S /bin/bash
#$ -cwd                 # Job runs in current directory - where submitted from
#$ -V                   # Job inherits current environment
#$ -pe smp.pe 16        # Run on all cores on an Intel node
#$ -l ivybridge         # Run on a sandybridge Intel node

java my_parallel_app_class arg1

12 core job – highmem compute node

This will run on a node that has 8GB per core. It is not possible to request 16 cores. We have a very limited number of this type of node, please do not use this option unless your job genuinely needs a lot of memory.

#!/bin/bash
#$ -S /bin/bash
#$ -cwd                 # Job runs in current directory - where submitted from
#$ -V                   # Job inherits current environment
#$ -pe smp.pe 12        # Run on all cores on an Intel node
#$ -l highmem           # Run on a sandybridge Intel node

java my_parallel_app_class arg1

Which compute node type should I run on?

All of the above examples are for all of the possible Intel node types and which of these you use makes very little difference for most java applications. The batch system spreads works as evenly as possible across all the different types of node so no one set of nodes is likely to be busier or quieter than another. Sandybridge or Ivybridge may be slightly faster in terms of run time.

Further info

• Javac compiler on the CSF

Updates

None.