As Java is a resource-intensive program, it should only be used on compute nodes. You can submit a job through the Slurm scheduler, load a Java module, and then run commands as needed. See this wiki page for general information on submitting interactive or batch jobs on O2.
We have several versions of Java on O2, which are accessible through our module system. Use the
module spider command to search for available Java modules.
Specifying path to jar file
There are multiple programs on O2, such as Trimmomatic, Picard, or IGVTools, for which the underlying code is written in Java. When you load a module for such a program, it will also automatically co-load a corresponding Java module for you. Then, when you run the program, you need to specify the full path to the JAR (archive file format that Java uses to package code and files required for program execution) like so:
We have made it easier to construct commands for each Java-based program that has a module on O2. When this type of module is loaded, an environment variable containing the directory of the JAR is set. You can run
module help on a specific module to learn the appropriate usage. Here is an example demonstrated using the
To constrain the memory usage of your Java program, add
<size> is replaced with an amount of memory. This parameter will set the maximum heap size of the Java virtual machine. It is advantageous to add -
Xmx to ensure your program will not exceed the memory you requested for your job from the scheduler. For example, to set the heap size to 5G:
Commonly encountered problems
GUIs, like IGV, lag over X11
If you run a Java program with a graphical user interface (GUI) on O2 but display the graphics on your local computer using X11, you will find that program is slow to respond, or lags. This behavior is expected, as HPC clusters are not designed for this use case. An example of this scenario is if you have BAM files on O2 that you would like to visualize with IGV without moving the alignment files off of the cluster. Unfortunately, you will not the see same responsiveness from a graphical program like IGV running on O2 and displayed on your local computer using X11, as you would with running the program locally. Preferable solutions include: (1) downloading files from the cluster to open in IGV on a local computer, or (2) use the
/n/groups/genomebrower_uploads storage space, which will create a URL for your file than can be used on your local computer. Access to
/n/groups/genomebrower_uploads is granted by request-only, so write to email@example.com if you would like to use this space.
Overefficient jobs necessitate adjusting garbage collection settings
Sometimes, Java applications can be overefficient, and try to use more cores than were requested through the scheduler. We have now set by default the garbage collection to
-XX:+UseSerialGC in order to prevent the overefficiency problem, this would cause a conflict error if a user explicitly requests a parallel garbage collector.