{"id":1040,"date":"2018-11-26T15:11:21","date_gmt":"2018-11-26T15:11:21","guid":{"rendered":"http:\/\/ri.itservices.manchester.ac.uk\/csf3\/?page_id=1040"},"modified":"2025-10-27T11:13:32","modified_gmt":"2025-10-27T11:13:32","slug":"java","status":"publish","type":"page","link":"https:\/\/ri.itservices.manchester.ac.uk\/csf3\/software\/tools\/java\/","title":{"rendered":"Java"},"content":{"rendered":"

Overview<\/h2>\n

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.<\/p>\n

Java Runtime Environment Versions 1.8.0 is installed on the CSF. You do not need to load any module to use this version.
\nNote that loading the OPENJDK modulefile will also give you access to the OpenJDK development packages (including the javac<\/code> compiler).<\/p>\n

Restrictions on use<\/h2>\n

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<\/a> notes for more information on compiling Java code.<\/p>\n

Set up procedure<\/h2>\n

The default is 1.8.0. It is not necessary to load a modulefile for this version, but you can if you wish:<\/p>\n

\r\nmodule load tools\/java\/1.8.0           # Default version if no modulefile loaded\r\n\r\n# Other versions\r\nmodule load tools\/openjdk\/25.0.1       # JDK 25\r\nmodule load tools\/openjdk\/23.0.2       # JDK 23\r\nmodule load tools\/openjdk\/22.0.2       # JDK 22\r\nmodule load tools\/openjdk\/20.0.2       # JDK 20\r\nmodule load tools\/openjdk\/17.0.2       # JDK 17\r\nmodule load tools\/openjdk\/11.0.2       # JDK 11\r\n\r\n# Other versions (Not recommended<\/strong>. Use openjdk modules shown above instead)\r\nmodule load tools\/java\/23\r\nmodule load tools\/java\/22\r\nmodule load tools\/java\/11\r\n\r\n# These are no longer available on CSF3 (Slurm)\r\nmodule load tools\/java\/1.7.0           # NOT installed on CSF3 (Slurm)\r\nmodule load tools\/java\/1.6.0           # NOT installed on CSF3 (Slurm)\r\n<\/pre>\n
Running the application<\/h2>\n
Java will not run on the login node and you will receive the following error if you try to run java<\/code> there:<\/p>\n
Error occurred during initialization of VM\r\nCannot create VM thread. Out of system resources.\r\n<\/pre>\n
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.<\/p>\n
Serial batch job submission<\/h3>\n
You must<\/strong> 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:<\/p>\n
-XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1\r\n<\/pre>\n
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.<\/p>\n
-Xmx4G              # 4G tells Java it can use 4 GB of RAM\r\n<\/pre>\n
The above flags can be added to the java<\/code> command-line (see jobscript examples below). For example, the following jobscript will run a serial java program safely:<\/p>\n
\r\n#!\/bin\/bash --login\r\n#SBATCH -p serial  # Partition is required. Runs on an Intel hardware.\r\n                   # Or submit batch jobs to the \"interactive\" partition for AMD Genoa serial jobs.\r\n#SBATCH -t 4-0     # Wallclock limit (days-hours). Required!\r\n                   # Max permitted is 7 days (7-0).\r\n\r\nmodule purge\r\n# Load the modulefile tools\/openjdk\/25.0.1 in the jobscript\r\nmodule load tools\/openjdk\/25.0.1\r\n\r\njava -XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1 -Xmx4G my_app_class<\/em> arg1<\/em> arg2...<\/em>\r\n\r\n# If you have a .jar file:\r\njava -XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1 -Xmx4G -jar myapp.jar<\/em> arg1<\/em> arg2...<\/em>\r\n<\/pre>\n
Submit the jobscript using:<\/p>\n
sbatch scriptname<\/em><\/pre>\n
where scriptname<\/em> is the name of your jobscript.<\/p>\n
If you are running another application which uses Java, for example MATLAB or a python program that uses Java libraries (SK-Learn is an example), then you will need to check the documentation for that application to see how to pass the Java flags to the application. You could also try setting the environment variable _JAVA_OPTIONS<\/code> with a list of the flags. For example:<\/p>\n
\r\n#!\/bin\/bash --login\r\n#SBATCH -p serial  # Partition is required. Runs on an Intel hardware.\r\n                   # Or submit batch jobs to the \"interactive\" partition for AMD Genoa serial jobs.\r\n#SBATCH -t 4-0     # Wallclock limit (days-hours). Required!\r\n                   # Max permitted is 7 days (7-0).\r\n\r\nmodule purge\r\n# Load the modulefile tools\/openjdk\/25.0.1 in the jobscript\r\nmodule load tools\/openjdk\/25.0.1\r\n# Load the application module next\r\nmodule load my\/java\/dependent\/app\r\n\r\n# Add the following to a jobscript to set java options. Your application may\r\n# be able to use this setting and you should check if it has worked or not!\r\nexport _JAVA_OPTIONS=\"-XX:ParallelGCThreads=1 -XX:ParallelCMSThreads=1 -Xmx4G\"\r\n\r\n# Now the commands to run your app that uses java\r\nmyapp arg1<\/em> arg2...<\/em>\r\n<\/pre>\n
Submit the jobscript using:<\/p>\n
sbatch scriptname<\/em><\/pre>\n
where scriptname<\/em> is the name of your jobscript.<\/p>\n
Note that by setting the above environment variable, Java will usually create a log file in your home directory showing which settings have been applied. You should delete this file to keep your home directory tidy. You will have a different log file every time<\/em> you run a job that uses this environment variable.<\/p>\n
Parallel batch job submission<\/h3>\n
If your application uses Java Threads for parallelism then you should submit the job to the multicore_small<\/code> partition and request an appropriate number of cores.<\/p>\n
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<\/code> in Java). Hence you should submit a job of 32 or 24 cores as per the example below. This ensures you will have a entire node to yourself and so do not need to restrict the garbage collection threads or heap size. For example:<\/p>\n
Example Job Script<\/strong><\/p>\n
\r\n#!\/bin\/bash --login\r\n#SBATCH -p multicore_small  # Partition is required. Runs on haswell or skylake node.\r\n#SBATCH -C skylake          # skylake for 32 cores and 6GB\/core.\r\n                            # haswell for 24 cores and 5GB\/core.\r\n#SBATCH -n 32               # (or --ntasks=) select between 32 or 24.\r\n#SBATCH -t 4-0              # Wallclock limit (days-hours). Required!\r\n                            # Max permitted is 7 days (7-0).\r\n\r\n# Load the modulefile\r\nmodule load tools\/openjdk\/25.0.1\r\n\r\njava my_parallel_app_class<\/em> arg1<\/em> arg2...<\/em>\r\n<\/pre>\n
<\/p>\n
Further info<\/h2>\n