Jfeatures

Memory statistics for running Java application

2021-06-01T00:00:00+00:00

OutOfMemoryError is one of the most annoying problem java developers face. We get this error when the Java application is trying to add new objects to the heap and there is not enough space available. OpenJDK provides command-line utility jmap to troubleshoot memory related problems in a running Java application. The jmap command-line utility prints memory related statistics for a running JVM. That includes class loader statistics, information on objects awaiting finalization, histogram of the java object heap, and finally complete heap dump as well.

Reducing memory utilization is a big concern for JVM developers as well. Following are 2 important OpenJDK projects that aims to reduce the overall memory footprint of a Java application:

Project Lilliput: Developers at RedHat started project Lilliput for this. This project aims to reduce size of Java object headers in the Hotspot JVM from 128 bits to 64 bits or lesser, overall reducing Java’s memory footprint and improving performance.
Project Valhalla: This OpenJDK project improves Java’s memory density by making it easy to create compact, cache efficient data structures.

In this post, we will learn how to use different functionalities provided by jmap with help of examples.

Troubleshooting a running Java Application with jmap

jmap command

jmap [options] pid

options:    This represents the jmap command-line options.
pid:        The process ID for which the information specified by the options is to be printed.

Java program we will be analyzing in this post

This is Java program we will run to understand different features available in jmap

public class Test
{
   public static void main(String[] args)
   {
      while(true)
      {
      }
   }
}

For all our examples we will be using Java 17, as of writing this post it is built using JDK master branch. This post can help you to build JDK from the source.

java -version
openjdk version "17-internal" 2021-09-14
OpenJDK Runtime Environment (build 17-internal+0-adhoc.vipin.jdk)
OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc.vipin.jdk, mixed mode)

Running Java process:

java Test

After running this program, we will print process id using jcmd. For more details on jcmd see this post.

jcmd

Output:

3712 Test
8255 jdk.jcmd/sun.tools.jcmd.JCmd

pid 3712 is the java process ID, we will use this for all our examples in this post.

Printing class loader statistics of Java heap

This command connects to a running process and prints class loader statistics of Java heap:

jmap -clstats 3712

Output:

lassLoader         Parent              CLD*               Classes   ChunkSz   BlockSz  Type
0x0000000800051bb0  0x0000000000000000  0x00007f8ee038bcd0       2      1152       813  jdk.internal.loader.ClassLoaders$PlatformClassLoader
0x0000000000000000  0x0000000000000000  0x00007f8ee017a9f0     997    996864    938941  <boot class loader>
                                                                56     21760     13257   + hidden classes
0x0000000800051868  0x0000000800051bb0  0x00007f8ee02ae990       1       768       253  jdk.internal.loader.ClassLoaders$AppClassLoader
Total = 3                                                     1056   1020544    953264  
ChunkSz: Total size of all allocated metaspace chunks
BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)

Printing information on objects awaiting finalization

This command connects to a running process and prints information on objects awaiting finalization.

jmap -finalizerinfo 3712

Here is the output, it matches our expectation since our Java application is not creating objects that are eligible for finalization.

No instances waiting for finalization found

Printing histogram of java object heap

The majority of memory leak problems can be easily identified using Java object histogram. We can take histogram a couple of times and analyze the number of objects created in this duration. In this way, we can identify anomalies in the number of Objects created.

This command connects to a running process and prints a histogram of the Java object heap. Here we are using live sub-option to counts only live objects.

jmap -histo:live 3712

Output:

num     #instances         #bytes  class name (module)
-------------------------------------------------------
1:          8437         449688  [B (java.base)
2:          7952         190848  java.lang.String (java.base)
3:          1084         132720  java.lang.Class (java.base)
4:          3298         105536  java.util.HashMap$Node (java.base)
5:           809          72200  [Ljava.lang.Object; (java.base)
6:           340          55232  [Ljava.util.HashMap$Node; (java.base)
...
...

Following is the part of jmap --help command, it shows the other histogram options available.

histo-options:
  live         count only live objects (takes precedence if both "live" and "all" are specified)
  all          count all objects in the heap (default if one of "live" or "all" is not specified)
  file=<file>  dump data to <file>
  parallel=<number>  parallel threads number for heap iteration:
                              parallel=0 default behavior, use predefined number of threads
                              parallel=1 disable parallel heap iteration
                              parallel=<N> use N threads for parallel heap iteration

It is not quick and easy to analyze huge heap dump files on local desktop due to memory limitation, this is where histogram feature becomes very helpful.

Taking Java process Heap dump

When the histogram can not help, we can take the full heap dump from the Java application and analyze it using external tools like Eclipse MAT. This command connects to a running Java process and dumps the heap.

jmap -dump:live,format=b,file=heap.bin 3712

Output:

Dumping heap to /home/vipin/heap.bin ...
Heap dump file created [3384326 bytes in 0.017 secs]

Following is the part of jmap --help command, that provides other dump options available.

dump-options:
  live         dump only live objects (takes precedence if both "live" and "all" are specified)
  all          dump all objects in the heap (default if one of "live" or "all" is not specified)
  format=b     binary format
  file=<file>  dump heap to <file>
  gz=<number>  If specified, the heap dump is written in gzipped format using the given compression level.
               1 (recommended) is the fastest, 9 the strongest compression.

JDK16 feature Taking gzipped heap dump

What is the first thing we do after taking a heap dump? we compress the big dump file that makes it easy to transfer on a personal computer. JDK-16 introduced gz option to take gzipped heap dump.

gz=1 is fastest and recommended compression level. Below is example command:

jmap -dump:live,format=b,file=heap.bin_1,gz=1 3712

Output:

Dumping heap to /home/vipin/heap.bin_1 ...
Heap dump file created [771184 bytes in 0.029 secs]

gz=9 is generating the smallest file. Below is example command:

jmap -dump:live,format=b,file=heap.bin_9,gz=9 3712

Output:

Dumping heap to /home/vipin/heap.bin_9 ...
Heap dump file created [600388 bytes in 0.586 secs]

Conclusion

jmap is a very useful command to check memory statistics of a running Java application. Knowing jmap features like histogram saves a lot of time in troubleshooting Java application memory issues. jmap is part of JDK itself, no need to install any third party software.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Analyzing hung Java process

2021-05-29T00:00:00+00:00

This is a draft post, work in progress:

jhsdb is a Serviceability Agent (SA) tool. Serviceability Agent (SA) is a JDK component used to provide snapshot debugging, performance analysis and to get an in-depth understanding of the Hotspot JVM, and the Java application executed by the Hotspot JVM.

Even though native debuggers like gdb are available for examining the JVM, unlike jhsdb, these native debuggers do not have an inbuilt understanding of the data structures in Hotspot and hence, are not able to throw insights on the Java application being executed. jhsdb knows about the locations and address ranges of crucial components of the JVM like the Java heap, heap generations, regions, code cache, etc.

We use the jhsdb tool to attach to a hanged Java process or to a core dump from a crashed Java Virtual Machine (JVM).

Troubleshooting a Java Application with jhsdb

jhsdb modes

Following are 7 modes available in jhsdb

jhsdb clhsdb    Starts the interactive command-line debugger.
jhsdb debugd    Starts the remote debug server.
jhsdb hsdb      Starts the interactive GUI debugger.
jhsdb jstack    Prints stack and locks information.
jhsdb jmap      Prints heap information.
jhsdb jinfo     Prints basic JVM information.
jhsdb jsnap     Prints performance counter information.

Structure of commands

Following is structure of commands to use with jhsdb.

jhsdb clhsdb [--pid pid | --exe executable --core coredump]

jhsdb debugd [options] (pid | executable coredump) [--serverid]

jhsdb hsdb [--pid pid | --exe executable --core coredump]

jhsdb jstack [--pid pid | --exe executable --core coredump] [options]

jhsdb jmap [--pid pid | --exe executable --core coredump] [options]

jhsdb jinfo [--pid pid | --exe executable --core coredump] [options]

jhsdb jsnap [options] [--pid pid | --exe executable --core coredump]

--pid

The process ID to which the jhsdb tool should attach.

--serverid

An optional unique ID to use when multiple debug servers are running on the same remote host.

--exe

The Java executable file from which the core dump was produced.

--core

The core dump file to which the jhsdb tool should attach.

options

Each mode has its separate list of options, which we can see using help (e.g. jhsdb jstack --help)

Java program we will be debugging in this post

Following is the java class we are going to run and try to understand different features available in jhsdb.

import java.util.concurrent.*;
import java.util.concurrent.locks.*;

public class DeadlockAOS
{
    private static Lock lock1 = new ReentrantLock();
    private static Lock lock2 = new ReentrantLock();
    private static int number_of_threads=2;

    public static void main(String args[])
    {
        ExecutorService executorService = Executors.newFixedThreadPool(number_of_threads);
        for (int i=0; i<number_of_threads/2; i++)
        {
            executorService.execute(new Task1());
            executorService.execute(new Task2());
        }

        executorService.shutdown();

    }

    static class Task1 implements Runnable
    {
        @Override
        public void run()
        {
            while(true)
            {
                try
                {
                    lock1.lock();
                    lock2.lock();
                }
                catch(Exception e)
                {
                    System.out.println(e.getMessage());
                }

                finally
                {
                    lock1.unlock();
                    lock2.unlock();
                }
            }

        }

    }

    static class Task2 implements Runnable
    {
        @Override
        public void run()
        {
            while(true)
            {
                try
                {
                    lock2.lock();
                    lock1.lock();
                }
                catch(Exception e)
                {
                    System.out.println(e.getMessage());
                }

                finally
                {
                    lock2.unlock();
                    lock1.unlock();
                }

            }
        }

    }

}

For all our examples we will be using Java 17, as of writing this post it is built using JDK master branch. This post explains how to build JDK from the source.

java -version
openjdk version "17-internal" 2021-09-14
OpenJDK Runtime Environment (build 17-internal+0-adhoc.vipin.jdk)
OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc.vipin.jdk, mixed mode)

Connecting jhsdb with Java process

Following are three ways to connect jhsdb with a Java process:

–pid option: Provide process id to connect with process (e.g. jhsdb jstack –pid 1234)
–core option: Use core dump file to connect with process (e.g. jhsdb jstack –core ./core.1234 –exe ./myexe)
–connect option: Start debug server using jhsdb debugd and use connect option (e.g. jhsdb jstack –connect id@debugserver:1234)

Using pid to connect with a hanged process

It is important to note we are trying to connect with a hanged process, if process is running it may get hang after we connect with jhsdb. Following command connects jhsdb with a java process and executes it in jstack mode to get thread dump:

jhsdb jstack --pid 26697

Following are some command showing clhsdb mode.

This is command to connect jhsdb with pid 26697

jhsdb clhsdb --pid 26697
Attaching to process 26697, please wait...

After attaching jhsdb threads command fetches list of threads along with thread ids.

hsdb> threads
...
26758 pool-1-thread-2
State: BLOCKED
Stack in use by Java: 0x00007f92ca8835a0 .. 0x00007f92ca883a78
Base of Stack: 0x00007f92ca885000
Last_Java_SP: 0x00007f92ca8835a0
Last_Java_FP: 0x00007f92ca883610
Last_Java_PC: 0x00007f930900d84b
Thread id: 26758
...

In this following command we are trying to get stack trace for thread id 26758

hsdb> where 26758
Thread 26758 Address: 0x00007f93183ec510

Java Stack Trace for pool-1-thread-2
Thread state = BLOCKED
- public native void park(boolean, long) @0x00007f92cb8c7f58 @bci = 0, pc = 0x00007f930900d87a (Interpreted)
    - parking to wait for <0x0000000452e9c678> (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
- public static void park(java.lang.Object) @0x00007f92cb9a1e50 @bci = 14, line = 211, pc = 0x00007f930900924a (Interpreted)
- final int acquire(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node, int, boolean, boolean, boolean, long) @0x00007f92cbbdc218 @bci = 347, line = 715, pc = 0x00007f930900924a, oop = 0x0000000452e9c678 (Interpreted)
- public final void acquire(int) @0x00007f92cbbdc8d0 @bci = 15, line = 938, pc = 0x00007f930900935e, oop = 0x0000000452e9c678 (Interpreted)
- final void lock() @0x00007f92cbce6cc0 @bci = 9, line = 153, pc = 0x00007f930900924a, oop = 0x0000000452e9c678 (Interpreted)
- public void lock() @0x00007f92cb99f778 @bci = 4, line = 322, pc = 0x00007f930900924a, oop = 0x0000000452e9c528 (Interpreted)
- public void run() @0x00007f92cbc0e978 @bci = 11, line = 61, pc = 0x00007f93090096ba, oop = 0x0000000452e9fd88 (Interpreted)
- final void runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @0x00007f92cbcec6d8 @bci = 92, line = 1135, pc = 0x00007f93090096ba, oop = 0x0000000452e9cc30 (Interpreted)
- public void run() @0x00007f92cbc40680 @bci = 5, line = 635, pc = 0x00007f930900924a, oop = 0x0000000452e9fd98 (Interpreted)
- public void run() @0x00007f92cb844170 @bci = 11, line = 831, pc = 0x00007f93090096ba, oop = 0x0000000452e9fdc8 (Interpreted)

Connecting jhsdb with core dump file

When Java process has generated core dump file, we can connect this with jhsdb and do further analysis e.g. take thread dump, heap dump.

First command to connect jhsdb with core dump file, filename: core

jhsdb clhsdb --core ./core --exe /home/vipin/githubprojects/jdk/build/linux-x86_64-server-fastdebug/jdk/bin/java
Opening core file, please wait...
hsdb>

This is command to get list of threads along with thread ids.

hsdb> threads
...
37825 pool-1-thread-2
State: BLOCKED
Stack in use by Java: 0x00007f24e78f65a0 .. 0x00007f24e78f6a78
Base of Stack: 0x00007f24e78f8000
Last_Java_SP: 0x00007f24e78f65a0
Last_Java_FP: 0x00007f24e78f6610
Last_Java_PC: 0x00007f254500d84b
Thread id: 37825
...

In this following command we are trying to get stack trace for thread id 37825

hsdb> where 37825
Thread 37825 Address: 0x00007f25543dc1f0

Java Stack Trace for pool-1-thread-2
Thread state = BLOCKED
- public native void park(boolean, long) @0x00007f251ccc7f58 @bci = 0, pc = 0x00007f254500d87a (Interpreted)
    - parking to wait for <0x0000000452e9c670> (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
- public static void park(java.lang.Object) @0x00007f251cda1e50 @bci = 14, line = 211, pc = 0x00007f254500924a (Interpreted)
- final int acquire(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node, int, boolean, boolean, boolean, long) @0x00007f251cfdc218 @bci = 347, line = 715, pc = 0x00007f254500924a, oop = 0x0000000452e9c670 (Interpreted)
- public final void acquire(int) @0x00007f251cfdc8d0 @bci = 15, line = 938, pc = 0x00007f254500935e, oop = 0x0000000452e9c670 (Interpreted)
- final void lock() @0x00007f251d0e6cc0 @bci = 9, line = 153, pc = 0x00007f254500924a, oop = 0x0000000452e9c670 (Interpreted)
- public void lock() @0x00007f251cd9f778 @bci = 4, line = 322, pc = 0x00007f254500924a, oop = 0x0000000452e9c520 (Interpreted)
- public void run() @0x00007f251d00e978 @bci = 11, line = 61, pc = 0x00007f25450096ba, oop = 0x0000000452e9fd80 (Interpreted)
- final void runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @0x00007f251d0ec6d8 @bci = 92, line = 1135, pc = 0x00007f25450096ba, oop = 0x0000000452e9cc28 (Interpreted)
- public void run() @0x00007f251d040680 @bci = 5, line = 635, pc = 0x00007f254500924a, oop = 0x0000000452e9fd90 (Interpreted)
- public void run() @0x00007f251cc44170 @bci = 11, line = 831, pc = 0x00007f25450096ba, oop = 0x0000000452e9fdc0 (Interpreted)

Starting debugd server and connecting using –connect option

Following is command to start debug server:

jhsdb debugd --pid 5069 --serverid test

This is command to connect with the server we started in above thread:

jhsdb jstack --connect test@localhost

Following is command to connect jhsdb in clhsdb mode, after this we can use all the clhsdb specific commands.

jhsdb clhsdb --pid 48584

Conclusion

Utilities like this are very useful in a situation when we need to analyze and resolve problems in production Java application quickly. jhsdb is an amazing utility part of JDK itself, no need to install any third party software.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

Java tools reference

What are my command-line flags, and the system properties for running Java process

2021-05-28T00:00:00+00:00

Imagine a situation when you observe a memory leak in production java application, and with increasing memory usages you know it can throw OutOfMemoryError in some time. You have not set HeapDumpOnOutOfMemoryError and HeapDumpPath flags while starting the Java application. This being your production application, now you can not restart application immediately and set these flags. In such a situation jinfo can be great help, it can help us to set these flags for a running Java application. We will see this particular example later in the post. While troubleshooting production Java application often we need to check command line flags passed to JVM, arguments passed to the main function, and system properties. jinfo is a very helpful command to get this information.

Troubleshooting a Java Application with jinfo

In this section, we will see how to use jinfo with a running Java process.

Command structure

jinfo [option] pid

option: This represents the jinfo command-line options, we will how to use these options later in this post.
pid:    The process ID for which the configuration information is to be printed.

Java program we will be analyzing in this post

Following is Java class we will run to understand different features available in jinfo

public class Test
{
   public static void main(String[] args)
   {
      while(true)
      {
      }
   }
}

For all our examples we will be using Java 17, as of writing this post it is built using JDK master branch. This post can help you to build JDK from source.

We are running Java process using below command:

java -XX:ConcGCThreads=6 -Xmx256m -Xms8m -Xss256k -DTEST_ARGUMENT=1 Test argument1 argument2

This command prints java process ids, see this blog post to read more about jps.

jps -ml

Output:

10000 Test argument1 argument2
10071 jdk.jcmd/sun.tools.jcmd.JCmd -l

pid 10000 is the java process we will use in rest of the post.

jinfo help command

This is jinfo help command, it prints usage instructions and all the options available in jinfo

jinfo --help

Output of help command:

Usage:
jinfo <option> <pid>
(to connect to a running process)

where <option> is one of:
-flag <name>         to print the value of the named VM flag
-flag [+|-]<name>    to enable or disable the named VM flag
-flag <name>=<value> to set the named VM flag to the given value
-flags               to print VM flags
-sysprops            to print Java system properties
<no option>          to print both VM flags and system properties
-? | -h | --help | -help to print this help message

Print command-line flags passed to the JVM

This command prints command-line flags passed to the JVM

jinfo -flags 10000

Output:

VM Flags:
-XX:CICompilerCount=12 -XX:ConcGCThreads=3 -XX:G1ConcRefinementThreads=13 -XX:G1HeapRegionSize=8388608 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=788529152 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=12616466432 -XX:MaxNewSize=7566524416 -XX:MinHeapDeltaBytes=8388608 -XX:MinHeapSize=8388608 -XX:NonNMethodCodeHeapSize=7602480 -XX:NonProfiledCodeHeapSize=122027880 -XX:ProfiledCodeHeapSize=122027880 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:SoftMaxHeapSize=12616466432 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC

Print a particular command-line flag in running Java process

This command prints value of a particular flag UseG1GC:

jinfo -flag UseG1GC 10000

Output:

-XX:+UseG1GC

Another example to print flag CICompilerCount

jinfo -flag CICompilerCount 10000

Output:

-XX:CICompilerCount=12

Print Java system properties as name-value pairs

This command prints system properties:

jinfo -sysprops 10000

Output:

Java System Properties:
#Sun Jun 27 11:02:17 IST 2021
java.specification.version=17
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
sun.jnu.encoding=UTF-8
java.runtime.version=17-internal+0-adhoc.vipin.jdk
...
...

Printing all 3, system properties, VM flags, and VM arguments

This is jinfo command to print system properties, VM flags, and VM arguments:

jinfo 10000

Output:

Java System Properties:
#Sun Jun 27 11:02:17 IST 2021
java.specification.version=17
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
sun.jnu.encoding=UTF-8
java.runtime.version=17-internal+0-adhoc.vipin.jdk
...

VM Flags:
-XX:CICompilerCount=12 -XX:ConcGCThreads=6 -XX:G1ConcRefinementThreads=13 -XX:G1HeapRegionSize=1048576 -XX:GCDrainStackTargetSize=64 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/vipin -XX:InitialHeapSize=8388608 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=268435456 -XX:MaxNewSize=160432128 -XX:MinHeapDeltaBytes=1048576 -XX:MinHeapSize=8388608 -XX:NonNMethodCodeHeapSize=7602480 -XX:NonProfiledCodeHeapSize=122027880 -XX:ProfiledCodeHeapSize=122027880 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:SoftMaxHeapSize=268435456 -XX:ThreadStackSize=256 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC

VM Arguments:
jvm_args: -XX:ConcGCThreads=6 -Xmx256m -Xms8m -Xss256k -DTEST_ARGUMENT=1
java_command: Test argument1 argument2
java_class_path (initial): .
Launcher Type: SUN_STANDARD

Update manageable VM flags

jinfo can update manageable VM flags for a running Java application. While starting our Java application if we have not set HeapDumpOnOutOfMemoryError and HeapDumpPath flags, we can set these with jinfo.

This is the command to find all manageable flags, that can be updated for a running Java application.

jcmd 10000 VM.flags -all | grep manageable

Output:

uintx G1PeriodicGCInterval                    = 0                                      {manageable} {default}
double G1PeriodicGCSystemLoadThreshold        = 0.000000                               {manageable} {default}
bool HeapDumpAfterFullGC                      = false                                  {manageable} {default}
bool HeapDumpBeforeFullGC                     = false                                  {manageable} {default}
intx HeapDumpGzipLevel                        = 0                                      {manageable} {default}
bool HeapDumpOnOutOfMemoryError               = false                                  {manageable} {default}
ccstr HeapDumpPath                            =                                        {manageable} {default}
uintx MaxHeapFreeRatio                        = 70                                     {manageable} {default}
uintx MinHeapFreeRatio                        = 40                                     {manageable} {default}
bool PrintClassHistogram                      = false                                  {manageable} {default}
bool PrintConcurrentLocks                     = false                                  {manageable} {default}
bool ShowCodeDetailsInExceptionMessages       = true                                   {manageable} {default}
size_t SoftMaxHeapSize                        = 268435456                              {manageable} {ergonomic}

These are commands to update heap dump related flags:

jinfo -flag HeapDumpOnOutOfMemoryError=true 10000
jinfo -flag HeapDumpPath=/home/vipin 10000

Let’s check all flag values again, we can see HeapDumpOnOutOfMemoryError is true, and HeapDumpPath is set now.

$ jcmd 10000 VM.flags -all | grep manageable
uintx G1PeriodicGCInterval                      = 0                                      {manageable} {default}
double G1PeriodicGCSystemLoadThreshold          = 0.000000                               {manageable} {default}
bool HeapDumpAfterFullGC                        = false                                  {manageable} {default}
bool HeapDumpBeforeFullGC                       = false                                  {manageable} {default}
intx HeapDumpGzipLevel                          = 0                                      {manageable} {default}
bool HeapDumpOnOutOfMemoryError                 = true                                   {manageable} {default}
ccstr HeapDumpPath                              = /home/vipin                            {manageable} {attach}
uintx MaxHeapFreeRatio                          = 70                                     {manageable} {default}
uintx MinHeapFreeRatio                          = 40                                     {manageable} {default}
bool PrintClassHistogram                        = false                                  {manageable} {default}
bool PrintConcurrentLocks                       = false                                  {manageable} {default}
bool ShowCodeDetailsInExceptionMessages         = true                                   {manageable} {default}
size_t SoftMaxHeapSize                          = 268435456                              {manageable} {ergonomic}

Conclusion

jinfo is a very useful command to check VM flags, system properties and even we can set value of some VM flags. Utilities like this are very useful in a situation when we need to analyze and resolve problems in production Java application quickly. jinfo is part of JDK itself, no need to install any third party software.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Find all the Java processes running on your machine

2021-05-28T00:00:00+00:00

When your application has some problem, the first thing to check is running processes on the machine. For Linux OS we generally use ps -ef. ps is one of the most used Linux troubleshooting commands. JDK provides similar functionality for Java processes through jps. The jps command-line utility provides a list of all running Java processes on a machine for which the user has access rights. The access rights are determined by access-control mechanisms specific to the operating system. jps utility can also provide information on arguments passed to the main method, arguments passed to JVM, etc. In this post, we will see the functionalities provided by jps.

Troubleshooting a Java Application with jps

In this section, we will see how to use jps with a running Java process.

jps command

jps [options] pid

options:    This represents the jps command-line options.
pid:        The process ID for which the information specified by the options is to be printed.

Java program we will be debugging in this post

Following is the sample class we are going to debug and try to understand the different features available.

public class Test
{
   public static void main(String[] args)
   {
      while(true)
      {
      }
   }
}

For all our examples we will be using Java 17, as of writing this post it is built using JDK master branch. This post explains how to build JDK from the source.

java -version
openjdk version "17-internal" 2021-09-14
OpenJDK Runtime Environment (build 17-internal+0-adhoc.vipin.jdk)
OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc.vipin.jdk, mixed mode)

We are running the Java process using the following command. For rest of the blog post we will use jps on this process.

java -XX:ConcGCThreads=6 -Xmx256m -Xms8m -Xss256k Test argument1 argument2

Print Java process ids

Following command shows process ids.

jps -q

Output:

Print process id along with the class name

This is the command to list Java processes with main class names, it is same as command jps -V.

jps

Output:

2468
Jps
Main
Launcher
Test

Print Java process ids along with full package name

jps -l displays the full package name for the application’s main class or the full pathname to the application’s JAR file.

command:

jps -l

Output:

2468
jdk.jcmd/sun.tools.jps.Jps
com.intellij.idea.Main
org.jetbrains.jps.cmdline.Launcher
Test

Print process ids along with class name and arguments passed to the main method.

jps -m displays the arguments passed to the main method

jps -m

Output:

2468
Jps -m
Main
Launcher /home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/commons-lang3-3.10.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/httpclient-4.5.12.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/annotations.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/netty-buffer-4.1.52.Final.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/plugins/java/lib/jps-javac-extension-1.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/jdom.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/netty-resolver-4.1.52.Final.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/lib/maven-resolver-api-1.3.3.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/plugins/java/lib/maven-resolver-connector-basic-1.3.3.jar:/home/vipin/.local/share/JetBrains/Toolbox/apps/IDE
Test argument1 argument2

Print JVM arguments passed to Java process

jps -v displays the arguments passed to the JVM.

jps -v

Output:

-Djava.library.path=/tmp/.mount_jetbraH5N0hQ -Xmx256m -Xms8m -Xss256k -XX:+UseStringDeduplication -XX:+UseCompressedOops -XX:+UseSerialGC -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djdk.lang.processReaperUseDefaultStackSize=true vfprintf exit abort -DTOOLBOX_VERSION=1.20.7940
Jps -Dapplication.home=/home/vipin/githubprojects/jdk/build/linux-x86_64-server-release/jdk -Xms8m -Djdk.module.main=jdk.jcmd
Main -Xms128m -Xmx2048m -XX:ReservedCodeCacheSize=512m -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -Dide.no.platform.update=true -XX:ErrorFile=/home/vipin/java_error_in_idea_%p.log -XX:HeapDumpPath=/home/vipin/java_error_in_idea_.hprof -Didea.vendor.name=JetBrains -Didea.paths.selector=IdeaIC2020.3 -Djb.vmOptionsFile=/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57.vmoptions -Didea.platform.prefix=Idea -Didea.jre.check=true
Launcher -Xmx700m -Djava.awt.headless=true -Djdt.compiler.useSingleThread=true -Dpreload.project.path=/home/vipin/githubprojects/jdk -Dpreload.config.path=/home/vipin/.config/JetBrains/IdeaIC2020.3/options -Dcompile.parallel=false -Drebuild.on.dependency.change=true -Dio.netty.initialSeedUniquifier=4046065713679813272 -Dfile.encoding=UTF-8 -Duser.language=en -Duser.country=IN -Didea.paths.selector=IdeaIC2020.3 -Didea.home.path=/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57 -Didea.config.path=/home/vipin/.config/JetBrains/IdeaIC2020.3 -Didea.plugins.path=/home/vipin/.local/share/JetBrains/IdeaIC2020.3 -Djps.log.dir=/home/vipin/.cache/JetBrains/IdeaIC2020.3/log/build-log -Djps.fallback.jdk.home=/home/vipin/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/203.7148.57/jbr -Djps.fallback.jdk.version=11.0.9.1 -Dio.netty.noUnsafe=true -Djava.io.tmpdir=/home/vipin/.cache/JetBrains/IdeaIC2020.3/compile-server/jdk_5c2ba8e3/_temp_ -Djps.backward.ref.index.builder=true -Dkotlin.incremental.compilation=true
Test -XX:ConcGCThreads=6 -Xmx256m -Xms8m -Xss256k

`jcmd` to list Java processes

jcmd or jcmd -l both provides similar information as jps -l. You can read more about jcmd on post.

Conclusion

jps is a simple tool with few options that make it easy to master, and when in need it can be a quick and great help you wanted. Utilities like this are very useful in a situation when we need to analyze and resolve problems in production Java application quickly. jps is part of OpenJDK, no need to install any third party software.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

Javadoc for jps

Avoid multithreading bugs using immutable Java Records

2021-04-13T12:00:00+00:00

In a multi-threaded Java application, any thread can change the state of an object. Java memory model in Java language specification specifies when exactly updates made by one thread are going to be visible to other threads. This is one of the biggest problems professional java developers deal with every day. Java records are immutable, an object is considered immutable if its state cannot change after it is constructed. The immutable nature of the record eliminates problems of its usages in a multithreaded environment.

Previous blog post on record explains how record provides a way to create data carrier-classes without writing a lot of boilerplate code. As part of this post, we will focus on the immutable feature of the record. Immutability is one of the best features provided by records, we can use a record object without worrying about other threads changing its state.

Java language features making record immutable

In this section, we will go through a table explaining how records are made immutable in the Java language. In the below table the 2nd column explains different ways to update the state of a record object, the 3rd column explains Java language features that prevent updating the state of the Record object.

Index	Way to update record	Java language features preventing it
1	Create a record sub-class and change the state of the sub-class.	Record classes are implicitly final and can not be abstract, this way we can not create a sub-class of the record class.
2	Extend some other class(superclass) and change the state of the superclass.	All record classes extend java.lang.Record by default so can not extend any other class.
3	Add instance fields that can be modified.	Record classes cannot declare instance fields.
4	Update record components.	We can not assign a new value to record components as these are implicitly final. These are assigned values while initializing the record in a canonical constructor.
5	Update record components in the constructor.	Only canonical constructor can update record components, which is called while initializing record. For other types of constructors, assigning any of the record components in the constructor body results in a compile-time error.
6	Update record components using reflection.	Record components have specific handling in Reflection *Field API. This treatment is like hidden classes. You can read more about Hidden classes here*.

Shallowly immutable

Record components are final, which means we can not change the record components once assigned. Although we can change fields of the record component, there is no restriction on that, it makes the record shallowly immutable. Let’s see this with an example.

public class EmployeeTest {

    public static void main(String[] args) {
        List<Integer> integerList = new ArrayList<>();
        integerList.add(1);
        IntegerListRecord integerListRecord = new IntegerListRecord(integerList);

        System.out.println(integerListRecord.getListSize());

        integerList.add(2);
        System.out.println(integerListRecord.getListSize());
    }
}

    record IntegerListRecord(List<Integer> integerList) {
        int getListSize()
        {
            return integerList.size();
        }
    }

In this example, we created a list of integers(integerList), added one element into it, and initialized the record class with this. Calling method getListSize of record class results into 1. Now we add one more element in integerList and calling getListSize results into 2. Here we did not change the record component (integerList) but updated the fields of the record component, which does not have any restriction. This is the reason we call the record shallowly immutable.

Conclusion

Records help you remove repetitive and error-prone code, and increases developer productivity. The immutability feature keeps it away from concurrency bugs. Using language features like this is going to make you a great developer everyone wants to hire.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

JEP 395
https://cr.openjdk.java.net/~briangoetz/amber/datum.html
Java language specification: Java memory model
Reflection Field API Javadoc.

Java Records: Data carrier classes

2021-03-14T12:00:00+00:00

Records

Professional Java developers need immutable data carrier-classes for communication with databases, web Services. We need to write a lot of boilerplate code to create a simple data carrier-class, we typically implement constructor, accessors, equals(), hashCode(), and toString(). This process is repetitive and error-prone. Developers also complain “Java is too verbose”.

Record classes provide a way to model data in java. An example of data is one row from a database table. This feature simplifies coding, makes java code more concise and readable. It is going to increase productivity for professional java developers. Java14 introduced Records as a preview feature, Java15 brings in some updates as a second preview and Java16 makes it a final feature, no changes in Record after this.

Common implementation use cases

1. Multiple return values: Often we encounter cases when we want to return multiple values from a method, for this we will have to create a class having values that we need to return. The record provides an easy way rather than writing boilerplate code.

2. Data transfer objects (DTO): Developers working with databases often write DTO which is typically used for storage only, we can again reduce boilerplate code using java Record classes.

Java code before and after Record

Following is one example showing Point class without using record.

class Point
{
 public final int x;   
 public final int y;    
 public Point(int x, int y) { this.x = x; this.y = y; }    
 public int getX() {...}   
 public int getY() {...}   
 public String toString() {...}   
 public boolean equals(Object o) {...}   
 public int hashCode() {...)  
}

Record equivalent for Point class is following one line, WOW !

record Point(int x, int y){}

In this example record class name is Point, and it has 2 components x,y that describes state. The record class can have a body as well, later in this post we have such examples.

We can use javap command to see the compiled class:

javac com/jfeatures/jdk16/records/Point.java 
javap -p com/jfeatures/jdk16/records/Point.class
 
Compiled from "Point.java"
final class com.jfeatures.jdk16.records.Point extends java.lang.Record {
  private final int x;
  private final int y;
  com.jfeatures.jdk16.records.Point(int, int);
  public final java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public int x();
  public int y();
}

In the above output of the javap command we can see the record classes have:

A private final field for each component in record declaration(state description). (In the above example private final int x, private final int y)
A public read accessor method for each component of the Record, with the same name and type as the parameter. (public int x(), public int y())
A public constructor, having the same arguments as the components of the record, is also called a canonical constructor. This constructor initializes each field from the corresponding argument. (com.jfeatures.jdk16.records.Point(int, int))
Implementations of equals and hashCode that say two record classes are equal if they are of the same type and contain the same state.
An implementation of toString that includes the string representation of all the record components, with their names.

Record classes in detail

Record classes behave like normal classes except restrictions, following are few properties of the Record classes:

Can be declared as top-level or nested, can be generic.
Can implement interfaces.
Are instantiated via the new keyword.
Record class body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types.
The record class and the individual components in a state description, can be annotated.
We can define a nested record class. Nested record is implicitly static, because an immediately enclosing instance can add a state to the record.
Instances of record classes can be serialized and deserialized. Serialization is done using Record components and deserialization is done using the canonical constructor. Serialization and deserialization can not be customized via regular means (writeObject, readObject, readObjectNoData, writeExternal, or readExternal methods).

Restrictions on record

Following code shows compilation error in extends, because Record classes are implicitly final.

record Base(int a) { }
record Child(int a, int b) extends Base { }

Similarly, we have a few more restrictions to follow for record classes.

Restrictions on Record classes can be divided into 3 categories:

Restrictions that ensure the record class components alone defines the representation
1. record classes cannot extend any other class
2. record classes cannot declare instance fields, only record components carry the state of the record object.
Restrictions that emphasize the API of a record is defined solely by its record components, and cannot be enhanced later by another class or record.
1. record classes are implicitly final.
2. record classes cannot be abstract.
3. record classes cannot declare native methods.
Restriction to make sure record is immutable by default.
1. The components of a record are implicitly final.

Constructors

Record classes have 3 types of constructors:

Canonical constructor: It contains all components of the record. This is declared implicitly, can be declared explicitly as well. Starting From Java15, if the canonical constructor is implicitly declared then its access modifier is the same as the record class. If the canonical constructor is explicitly declared then its access modifier must provide at least as much access as the record class.
```
record Employee(String name, int id) {
   Employee(String name, int id) {
       this.name = name;
       this.id = id;
   }
}
```
Compact canonical constructor: It doesn’t have any parameter, it is always called when defined. The compact form helps developers focus on validating and normalizing parameters. Here parameters are declared implicitly, and the private fields corresponding to record components are automatically assigned (this.x = x) at the end of the constructor.
```
record Employee(String name, int id) {
    Employee {
        //validation
        if(name.length()==0) throw new RuntimeException("Nota a valid name");
    }
}
```
For a Record class, only one out of canonical constructor or compact canonical constructor can be defined. Defining both results into compilation failure.
Custom constructor: We can create custom constructors as well having only a few parameters from the Record header. Since this is not a canonical constructor, its first statement must invoke another constructor of the record class.
```
record Employee(String name, int id) {
   public Employee(String name) {
       this(name, 0);
   }
}
```
Starting from Java 15 assigning any of the instance fields (record components) in the constructor body became a compile-time error. Only the canonical constructor is allowed to do this.

Update on @Override annotation

Java 15 extends the meaning of the @Override annotation to include an explicitly declared accessor method for a record. Now following is valid java code.

package com.jfeatures.jdk16.records;

public record Employee(String name, int id) {

    @Override
    public int id() {
        return id;
    }

    @Override
    public String name() {
        return name;
    }
}

Local record, enum, and interfaces are now allowed in Java

Java15 introduced the ability to declare local record classes, local enum classes, and local interfaces. Nested record classes and local record classes are implicitly static. It avoids adding an immediate enclosing instance to the state of the record class.

public class LocalComponents {
    public static void main(String[] args) {
        System.out.println("Start Test");
        new LocalComponents().instanceMethod();
    }

    void instanceMethod() {
        record LocalRecord(int x, int y) {
            LocalRecord {
                System.out.println("Inside Local Record compact canonical constructors");
            }
        }
        enum LocalEnum {
            VALUE1,
            VALUE2;
        }

        interface LocalInterface extends Cloneable {
        }
    }
}

For versions before Java15, above code will not compile. Following is a compilation error for local enum in above example.

com/jfeatures/jdk16/records/LocalComponents.java:16: error: enum types must not be local
enum LocalEnum {
^
1 error

Inner class can declare static members

Before Java 16, an inner class can not declare a static member. Java 16 allows the inner class to declare a member of the type record class. This will allow an inner class to declare a member that is a record class.

package com.jfeatures.jdk16.records;

public class RecordInInnerClass {
    public static void main(String[] args) {
        System.out.println("Starting test");
    }

    class Inner{
        record TestRecord(int id, String name){
        }
    }
}

This code shows below compilation error with Java 15, it works fine with Java16 or later.

javac --enable-preview -source 15 com/jfeatures/jdk16/records/RecordInInnerClass.java
com/jfeatures/jdk16/records/RecordInInnerClass.java:9: error: static declarations not allowed in inner classes
record TestRecord(int id, String name){
^
Note: com/jfeatures/jdk16/records/RecordInInnerClass.java uses preview language features.
Note: Recompile with -Xlint:preview for details.
1 error

Why record, why not just tuples?

A central aspect of Java’s philosophy is that “names” matter. A Person with properties firstName and lastName is clearer and safer than a tuple of String and String.

Conclusion

Records help you remove repetitive and error prone code, reduce bugs in your code, reduces verbosity in code, and increases developer productivity. Using language features like this is going to make you a great developer everyone wants to hire.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

https://openjdk.java.net/jeps/395
https://cr.openjdk.java.net/~briangoetz/amber/datum.html

Debugging Java app without IDE

2021-02-01T00:00:00+00:00

Some bugs are hard to replicate on personal computer but easily replicated on production or test machine, it is a common situation professional Java developers deal with. To debug such problems OpenJDK provides 2 tools, remote debugging and jdb. This post we will focus on jdb.

For Java applications typical production and test machines are linux servers without display manager, only command line tools are available. Here we can not use professional IDE like Intellij Idea, Eclipse or Netbeans. In such scenario we can use jdb. jdb is a command line debugger, it is part of OpenJDK.

Troubleshoot java application with the jdb Utility

jdb is available in jdk/bin directory. It uses the Java Debug Interface (JDI) to launch or connect to the target JVM. The Java Debug Interface (JDI) provides a Java programming language interface for debugging Java programming language applications. JDI is a part of the Java Platform Debugger Architecture.

This section we will see how to attach jdb to java application and start debugging and monitoring.

jdb command

This is format of the jdb command:

jdb [options] [classname] [arguments]

options:    This represents the jdb command-line options (e.g. attach, launch).
classname:  This represents the name of the main class to debug.
arguments:  This represents the arguments that are passed to the main() method of the class.

Java program we will be debugging in this post

Following is sample class we are going to debug and try to understand different features available. It is important to compile this class with -g option (javac -g Test.java). -g option generates all debugging information, including local variables. By default, only line number and source file information is generated.

public class Test
{
	public static void main(String[] args)
	{
		System.out.println("First Line of main function");
        System.out.println("Second Line of main function");
        System.out.println("Third Line of main function");
		
		int i=0;
		System.out.println("i: " + i);
		i = 2;
		System.out.println("i: " + i);

		while(true)
		{
		}
	}
}

Attach jdb to Java application

Below command is the most common way to start application with jdb debugger. Here we are not passing any jdb option, we have only passed class name Test. Class Test doesn’t require any argument.

jdb Test

In this way we start executing main class Test in the similar way we start in professional IDE eclipse or intellij. jdb stops the JVM before executing that class’s first instruction.

Another way to use the jdb command is by attaching it to a JVM that’s already running. Syntax for starting JVM with debugger port is:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 Test

To attach jdb with this remote jvm use below syntax:

jdb -attach 5005

For this post we will not see remote debugging in detail.

debugging and monitoring

Following is the command to attach jdb with Java program Test:

/jdk/bin/jdb Test
Initializing jdb ...

Setting a break point at line number 5 using stop:

> stop at Test:5
Deferring breakpoint Test:5.
It will be set after the class is loaded.

Start execution of application’s main class using run:

> run
run  Test
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint Test:5

Breakpoint hit: "thread=main", Test.main(), line=5 bci=0
5    		System.out.println("First Line of main function");

execute current line using step:

main[1] step

> First Line of main function

Step completed: "thread=main", Test.main(), line=6 bci=8
6            System.out.println("Second Line of main function");

execute current line using step:

main[1] step

> Second Line of main function

Step completed: "thread=main", Test.main(), line=7 bci=16
7            System.out.println("Third Line of main function");

execute current line using step:

main[1] step
> Third Line of main function

Step completed: "thread=main", Test.main(), line=9 bci=24
9    		int i=0;

execute current line using step:

main[1] step
>
Step completed: "thread=main", Test.main(), line=10 bci=26
10    		System.out.println("i: " + i);

printing local variable i using print:

main[1] print i
i = 0

printing all local variables in current stack frame using locals:

main[1] locals
Method arguments:
args = instance of java.lang.String[0] (id=841)
Local variables:
i = 0

dump a thread’s stack using where:

main[1] where
[1] Test.main (Test.java:10)

list threads in running application using threads:

main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)804 Reference Handler   running
(java.lang.ref.Finalizer$FinalizerThread)805  Finalizer           cond. waiting
(java.lang.Thread)806                         Signal Dispatcher   running
(java.lang.Thread)803                         Notification Thread running
Group main:
(java.lang.Thread)1                           main                running
Group InnocuousThreadGroup:
(jdk.internal.misc.InnocuousThread)807        Common-Cleaner      cond. waiting

continue execution from the breakpoint using cont:

main[1] cont
> i: 0
i: 2

All available commands in jdb using help:

main[1] help
** command list **
connectors                -- list available connectors and transports in this VM

run [class [args]]        -- start execution of application's main class

threads [threadgroup]     -- list threads
thread <thread id>        -- set default thread
suspend [thread id(s)]    -- suspend threads (default: all)
resume [thread id(s)]     -- resume threads (default: all)
where [<thread id> | all] -- dump a thread's stack
wherei [<thread id> | all]-- dump a thread's stack, with pc info
up [n frames]             -- move up a thread's stack
down [n frames]           -- move down a thread's stack
kill <thread id> <expr>   -- kill a thread with the given exception object
interrupt <thread id>     -- interrupt a thread

print <expr>              -- print value of expression
dump <expr>               -- print all object information
eval <expr>               -- evaluate expression (same as print)
set <lvalue> = <expr>     -- assign new value to field/variable/array element
locals                    -- print all local variables in current stack frame

classes                   -- list currently known classes
class <class id>          -- show details of named class
methods <class id>        -- list a class's methods
fields <class id>         -- list a class's fields

threadgroups              -- list threadgroups
threadgroup <name>        -- set current threadgroup

stop [go|thread] [<thread_id>] <at|in> <location>
-- set a breakpoint
-- if no options are given, the current list of breakpoints is printed
-- if "go" is specified, immediately resume after stopping
-- if "thread" is specified, only suspend the thread we stop in
-- if neither "go" nor "thread" are specified, suspend all threads
-- if an integer <thread_id> is specified, only stop in the specified thread
-- "at" and "in" have the same meaning
-- <location> can either be a line number or a method:
--   <class_id>:<line_number>
--   <class_id>.<method>[(argument_type,...)]
clear <class id>.<method>[(argument_type,...)]
-- clear a breakpoint in a method
clear <class id>:<line>   -- clear a breakpoint at a line
clear                     -- list breakpoints
catch [uncaught|caught|all] <class id>|<class pattern>
-- break when specified exception occurs
ignore [uncaught|caught|all] <class id>|<class pattern>
-- cancel 'catch' for the specified exception
watch [access|all] <class id>.<field name>
-- watch access/modifications to a field
unwatch [access|all] <class id>.<field name>
-- discontinue watching access/modifications to a field
trace [go] methods [thread]
-- trace method entries and exits.
-- All threads are suspended unless 'go' is specified
trace [go] method exit | exits [thread]
-- trace the current method's exit, or all methods' exits
-- All threads are suspended unless 'go' is specified
untrace [methods]         -- stop tracing method entrys and/or exits
step                      -- execute current line
step up                   -- execute until the current method returns to its caller
stepi                     -- execute current instruction
next                      -- step one line (step OVER calls)
cont                      -- continue execution from breakpoint

list [line number|method] -- print source code
use (or sourcepath) [source file path]
-- display or change the source path
exclude [<class pattern>, ... | "none"]
-- do not report step or method events for specified classes
classpath                 -- print classpath info from target VM

monitor <command>         -- execute command each time the program stops
monitor                   -- list monitors
unmonitor <monitor#>      -- delete a monitor
read <filename>           -- read and execute a command file

lock <expr>               -- print lock info for an object
threadlocks [thread id]   -- print lock info for a thread

pop                       -- pop the stack through and including the current frame
reenter                   -- same as pop, but current frame is reentered
redefine <class id> <class file name>
-- redefine the code for a class

disablegc <expr>          -- prevent garbage collection of an object
enablegc <expr>           -- permit garbage collection of an object

!!                        -- repeat last command
<n> <command>             -- repeat command n times
# <command>               -- discard (no-op)
help (or ?)               -- list commands
dbgtrace [flag]           -- same as dbgtrace command line option
version                   -- print version information
exit (or quit)            -- exit debugger

<class id>: a full class name with package qualifiers
<class pattern>: a class name with a leading or trailing wildcard ('*')
<thread id>: thread number as reported in the 'threads' command
<expr>: a Java(TM) Programming Language expression.
Most common syntax is supported.

Startup commands can be placed in either "jdb.ini" or ".jdbrc"
in user.home or user.dir

coming out of jdb:

quit

Conclusion

OpenJDK provides many amazing troubleshooting and diagnosis tools. These tools help you to fix issues in your production application quickly. jdb can be a great help when there is no way other than debugging the application, and your favourite IDE is not available.

Knowing features like this helps you get the best java jobs, that’s why to help you I wrote ebook 5 steps to Best Java Jobs. Download this step-by-step guide for free!

Resources:

JCStress

2020-12-26T00:00:00+00:00

What is JCStress

Writing concurrent programs is hard, testing the concurrent program is harder, and debugging the concurrent program is a nightmare. The incorrect concurrent program can run for years, tricking us to believe it is stable code, and it fails when we least expect.

JCStress is a concurrency stress test tool used by JVM developers to test the correctness of the JVM itself! OpenJDK provides this amazing tool to test the correctness of your concurrent programs.

Starting with first JCStress test

We configure JCStress tests using annotations provided by JCStress framework. Following are important annotations help us to understand our first JCStress test.

@Actor: It annotates methods that hold the actions done by the threads.

@State: It annotates the class that holds the data mutated/read by the tests.

@Result:    This annotation marks the result object.

@JCStressTest:  Mark the class as JCStress test.

@Outcome:   It describes the test outcome, and how to deal with it.

This is a basic example of the JCStress test using annotations we discussed.

@JCStressTest

// These are the test outcomes.
@Outcome(id = "1, 1", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Both actors came up with the same value: atomicity failure.")
@Outcome(id = "1, 2", expect = Expect.ACCEPTABLE, desc = "actor1 incremented, then actor2.")
@Outcome(id = "2, 1", expect = Expect.ACCEPTABLE, desc = "actor2 incremented, then actor1.")

// This is a state object
@State
public class APISample_01_Simple {

    int v;

    @Actor
    public void actor1(II_Result r) {
        r.r1 = ++v; // record result from actor1 to field r1
    }

    @Actor
    public void actor2(II_Result r) {
        r.r2 = ++v; // record result from actor2 to field r2
    }

}

Following are few important points about the above test:

Class APISample_01_Simple has a field int v, it is annotated with @State, and it stores the state of the object.
For each test executed:
1. Methods actor1 and actor2 are executed exactly once.
2. Methods actor1 and actor2 are called by particular threads, e.g. Thread t1 calls actor1, and Thread t2 calls actor2.
3. Per @State object (here an instance of APISample_01_Simple) JCStress framework calls actor1 and actor2 only once.
4. The invocation order of methods actor1 and actor2 is deliberately not specified.
5. It stores the state in the same instance of APISample_01_Simple and records the result in the same instance of II_Result.
6. Result is available in the instance of II_Result after actor1 and actor2 are completed.
Class II_Result is annotated with @Result, to store the result of the test it usages 2 int type fields r1 and r2.
Depending upon the output of the test we tag it with corresponding @Outcome. e.g. for r1=1 and r2=2, the result is Expect.ACCEPTABLE. for r1=1 and r2=1, result is Expect.ACCEPTABLE_INTERESTING.

Setting up a project and how to run JCStress test

To use jcstress in your project, it is recommended to create the submodule with the jcstress tests, which would use jcstress libraries and build steps.

Easy and quick way to create jcstress project is to create a standalone JCStress project using maven archetype, for this you need maven and JDK 8+.

mvn archetype:generate \
 -DinteractiveMode=false \
 -DarchetypeGroupId=org.openjdk.jcstress \
 -DarchetypeArtifactId=jcstress-java-test-archetype \
 -DgroupId=com.jfeatures \
 -DartifactId=jcstresstest \
 -Dversion=1.0

This is a Github project created using the above command.

Running tests, if we have not created any test it will execute default test available.

cd jcstresstest
mvn clean install
java -jar target/jcstress.jar

In case we want to execute a particular test use -t option like below

java -jar target/jcstress.jar -t ConcurrencyTest

Open test report:

firefox results/index.html

More JCStress APIs

JCStress provides useful APIs to develop Java concurrency tests. In this section, we are going to discuss these APIs and how they solve different types of problems.

Using Result classes in JCStress

JCStress ships lots of pre-canned result classes. e.g. II_Result and III_Result, here I represent an int. The following is a list of different letters used in JCStress result classes.

I: 	int
Z: 	boolean
F:	float
J:	long
S: 	short
B:	byte
C:	char
D:	double
L:	object

With help of this, we can try to find a pre canned Result class in JCStress. e.g

for Result having int(I) and boolean(Z) we can use IZ_Result.
for Result having float(F) and long(J) we can use FJ_Result.

Arbiters

The method annotated with @Arbiter runs after all method annotated with @Actor are executed and therefore can observe the final result. This is a test using Arbiters.

Signal

The signal is useful for delivering a termination signal to the Actor in Mode.Termination tests. It will run after Actor in question started executing. For the termination test, we use annotation @JCStressTest(Mode.Termination). This is a test using Signal.

Nested tests

It is sometimes convenient to put the tests in the same source file for better comparison. JCStress allows to nest the tests. This is a test showing nested tests in JCStress.

Shared Metadata

Shared Metadata is used when more than one test share the outcomes and other metadata. To use common metadata for such tests, there is a special annotation @JCStressMeta. We can specify class in annotation @JCStressMeta to use metadata of that class. This is a test class having example of metadata.

Adding test descriptions and references

JCStress also allows putting the descriptions and references right at the test. It helps to identify the goal for the test, as well as the discussions about the behavior in question.

Following are the annotations to add the descriptions and references

@Description("Sample Hello World test")
@Ref("http://openjdk.java.net/projects/code-tools/jcstress/")

VM options and command line options used by JCStress

Vm options

-XX:+StressLCM -XX:+StressGCM

LCM stands for Local Code Motion, GCM stands for Global Code Motion.

For performance optimization compiler may reorder independent instructions without changing the semantics of the code. The compiler tries to find the most optimal order of instructions.

When we use StressLCM and StressGCM options, the instruction scheduling works differently. It chooses a random instruction order which is allowed under the Java memory model. It helps to simulate different scenarios
-XX:-TieredCompilation -XX:TieredStopAtLevel=1

Use -XX:-TieredCompilation or -XX:TieredStopAtLevel=1 to disable C1 or C2 respectively.
-Xint

Runs the application in interpreted-only mode. Compilation to native code is disabled, and all bytecode is executed by the interpreter. The performance benefits offered by the just in time (JIT) compiler are not present in this mode.

Command line options

JCStress has got a couple of helpful command line options. we can pass option -h to get a full list of command line options.

  java -jar target/jcstress.jar -h

Some important options are:

  Modes (-m)
  Test name(-t)
  verbose result (-v)
  Number of CPUs used (-c)

option -m

It sets test mode, from sanity to stress it goes from simple test to more rigorous, and for concurrency issues more rigorous is more helpful. At least once we should run our test with stress option, and then we can run tests in the quick mode as part of CI. Following are sample commands to run different modes.

java -jar target/jcstress.jar -t ConcurrencyTest -m sanity
java -jar target/jcstress.jar -t ConcurrencyTest -m quick
java -jar target/jcstress.jar -t ConcurrencyTest -m default
java -jar target/jcstress.jar -t ConcurrencyTest -m tough
java -jar target/jcstress.jar -t ConcurrencyTest -m stress

Conclusion

Knowing features like this helps you get the best java jobs, that’s why to help you I wrote ebook 5 steps to Best Java Jobs. Download this step-by-step guide for free!

Resources:

JCStress GitHub

Hidden Class

2020-12-01T01:00:00+00:00

What are hidden classes in Java 15

As we know sun.misc.Unsafe APIs are not recommended to use outside JDK, with slight mistake it may result in the JVM crash. In some cases code may not be portable across different platforms and many other problems.

On the other hand, there are some useful features Unsafe APIs provide and we don’t have an alternative for those as a standard language feature. To remove Unsafe API usages JDK developers provide standard language features, hidden class is one such feature. After introducing hidden classes sun.misc.Unsafe::defineAnonymousClass is deprecated in Java 15, which will be removed in future releases.

Classes that cannot be used directly by the bytecode of other classes are hidden classes. Hidden classes allow frameworks/JVM languages to define classes as non-discoverable implementation details, so that they cannot be linked against by other classes.

The following properties of the hidden class help us understand it better.

cannot be named as a supertype
cannot be a declaring field type
cannot be the parameter type or the return type
cannot be found by classloader via Class::forName, ClassLoader::loadClass, Lookup::findClass etc.

Why do we need hidden classes

Framework/Language implementors usually intend for a dynamically generated class to be logically part of the implementation of a statically generated class.

Following properties are desirable for dynamically generated classes:

Non-discoverability Dynamically generated classes should not be discoverable by other classes in JVM. (e.g. using Class::forName and ClassLoader::loadClass)
Lifecycle Dynamically generated classes may only be needed for a limited time, so retaining them for the lifetime of the statically generated class might unnecessarily increase memory footprint. Existing workarounds for this situation, such as per-class class loaders, are cumbersome and inefficient.
Access control It may be desirable to extend the access control context of the statically generated class to include the dynamically generated class.

Existing standard APIs ClassLoader::defineClass and Lookup::defineClass always define a visible/discoverable class and in this way classes have a longer lifecycle than desired. Hidden classes are dynamically generated and have all the above 3 features desired by Framework/Language implementors.

How to write hidden classes

The hidden class is created by invoking Lookup::defineHiddenClass. It causes the JVM to derive a hidden class from the supplied bytes, links the hidden class, and return a lookup object that provides reflective access to the hidden class.

Following are 4 steps creating and using hidden classes:

Step 1: Create Lookup object

Get a lookup object, which will be used to create hidden class in the next steps.

MethodHandles.Lookup lookup = MethodHandles.lookup();

Step 2: Create class bytes using ASM

We are using the byte code manipulation library ASM. We create ClassWriter object using helper class GenerateClass. If you look at details in GenerateClass, this class implements interface Test, which we will use in further steps.

ClassWriter cw = GenerateClass.getClassWriter(HiddenClassDemo.class);
byte[] bytes = cw.toByteArray();

Sep 3: Define hidden class

In this step, we are creating a hidden class. It is important to note the invoking program should store the lookup object carefully since it is the only way to obtain the Class object of the hidden class.

Class<?> c = lookup.defineHiddenClass(bytes, true, NESTMATE).lookupClass();

Step 4: Use hidden class

In this step, we are using reflection to access the hidden class. first, create the constructor then create an object using this, typecast this object to interface Test and call method test. This method ignores the argument passed and prints “Hello test” on the console.

Constructor<?> constructor = c.getConstructor(null);
Object object = constructor.newInstance(null);
Test test = (Test) object;
test.test(new String[]{""});

Below is the overall structure of the code we discussed above. The complete code is available in my GitHub repo.

public class HiddenClassDemo {
    public static void main(String[] args) throws Throwable {
        // Step 1: Create lookup object.
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        
        //Step 2: Get ClassWriter objects and then covert that into byte array.
        ClassWriter cw = GenerateClass.getClassWriter(HiddenClassDemo.class);
        byte[] bytes = cw.toByteArray();
        
        //Sep 3: Define hidden class.
        Class<?> c = lookup.defineHiddenClass(bytes, true, NESTMATE).lookupClass();
        
        //Step 4: Creating constructor then Object of type Test and calling a simple function test. 
        Constructor<?> constructor = c.getConstructor(null);
        Object object = constructor.newInstance(null);
        Test test = (Test) object;
        test.test(new String[]{""});
        System.out.println("End of main method in class " + HiddenClassDemo.class.getName());
    }
}

public interface Test {
    void test(String[] args);
}

public static ClassWriter getClassWriter(Class<HiddenClassDemo> ownerClassName) {
        ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);

        cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, getHiddenClassName(ownerClassName),
                null, "java/lang/Object", new String[] {"com/vip/jfeatures/jdk15/hiddenclass/Test"});
        ...
        ...
        ...
            MethodVisitor mv = cw.visitMethod(ACC_PUBLIC, "test",
                                "([Ljava/lang/String;)V", null, null);
            mv.visitCode();
            mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
            mv.visitLdcInsn("Hello test");
            mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V");
            mv.visitInsn(RETURN);
            mv.visitMaxs(2, 1);
            mv.visitEnd();        

    }

Hidden Classes as Unsafe Alternative

Before Java15, non-standard API Unsafe::defineAnonymousClass was used to generate dynamic classes. We know Unsafe APIs are not recommended, hidden classes are right approach to generate dynamic classes now.

Before migrating from Unsafe::defineAnonymousClass to Lookup::defineHiddenClass (Hidden classes) we need to be aware of the following constraints:

Unlike Unsafe::defineAnonymousClass, hidden classes do not support constant-pool patching. This is one recent thread showing progress on the enhancement.
VM-anonymous classes (created using Unsafe::defineAnonymousClass) can be optimized by Hotspot JVM by annotation @ForceInline. This optimization is not available for hidden classes.
A VM-anonymous class can access protected members of its host class even if the VM-anonymous class exists in a different run-time package and is not a subclass of the host class. A hidden class can only access protected members of another class if the hidden class is in the same run-time package as, or a subclass of, the other class. There is no special access for a hidden class to the protected members of the lookup class.

Due to these constraints in Java 15, hidden classes are not a complete replacement for Unsafe::defineAnonymousClass.

The best example of hidden class usages is lambda expressions in the JDK code. JDK developers don’t want to expose classes generated by lambda expression so javac is not translating lambda expression into dedicated class, it generates bytecode that dynamically generates and instantiates a class to yield an object corresponding to the lambda expression when needed. Before Java 15 Unsafe::defineAnonymousClass was used in the lambda expression implementation, now it is migrated to use hidden classes.

Conclusion

Knowing language features like this helps you get the best java jobs, that’s why to help you I wrote ebook 5 steps to Best Java Jobs. Download this step by step guide for free!

Resources

Pattern matching for the instanceof operator

2020-09-06T01:00:00+00:00

Repetitive and error-prone code with instanceof pre java 14

Following is typical example of instanceof operator before java 14.

if (obj instanceof String)
{
  String s = (String) obj;
  int length = s.length();
}

Three tasks are done here:

Test (is obj a String?)
A conversion (casting obj to String)
The declaration of a new local variable (s) so we can use the string value.

This pattern has 3 problems.

It is tedious: doing both the type test and cast should be unnecessary (what else would you do after an instanceof test?).
This boilerplate: in particular, the three occurrences of the type String obfuscates the more significant logic that follows.
Repetition, repetition of String provides opportunities for errors to creep unnoticed into programs.

Java solves these problems by pattern matching. instanceof pattern matching is preview features in Java 14 and 15. Using this same code is written as below, here you will not see the three problems we discussed.

if (obj instanceof String s)
{
    int length = s.length();
}

It was basic example of instanceof pattern matching. It simplifies messy operations. We will take 2 more examples to show how it simplifies code.

1. Simplification of equals method implementation

For a class Point, we might implement equals() as follows

class Point
{
    int x;
    int y;
}

public boolean equals(Object o) {
    if (!(o instanceof Point))
        return false;
    Point other = (Point) o;
    return x == other.x 
        && y == other.y;
}

Using a pattern match instead, we can combine this into a single expression, eliminating the repetition and simplifying the control flow

public boolean equals(Object o) {
    return (o instanceof Point other)
        && x == other.x
        && y == other.y;
}

2. Simplifying if else chain with instanceof pattern matching

Following is the code of if else chain with instanceof before java 14

private static void oldInstanceOf(Object obj)
    {
        String formatted = "unknown";
        if (obj instanceof Integer) {
            int i = (Integer) obj;
            formatted = String.format("int %d", i);
        }
        else if (obj instanceof Byte) {
            byte b = (Byte) obj;
            formatted = String.format("byte %d", b);
        }
        else if (obj instanceof Long) {
            long l = (Long) obj;
            formatted = String.format("long %d", l);
        }
        else if (obj instanceof Double) {
            double d = (Double) obj;
            formatted = String.format("double %f", d);
        }
        else if (obj instanceof String) {
            String s = (String) obj;
            formatted = String.format("String %s", s);
        }
        System.out.println(formatted);
    }

Now below is the code of if else chain using instanceof pattern matching

    private static void newInstanceOf(Object obj) {
        String formatted = "unknown";
        if (obj instanceof Integer i) {
            formatted = String.format("int %d", i);
        }
        else if (obj instanceof Byte b) {
            formatted = String.format("byte %d", b);
        }
        else if (obj instanceof Long l) {
            formatted = String.format("long %d", l);
        }
        else if (obj instanceof Double d) {
            formatted = String.format("double %f", d);
        }
        else if (obj instanceof String s) {
            formatted = String.format("String %s", s);
        }
        System.out.println(formatted);
    }

Before going to details of this language feature it is worth understanding what exactly is the pattern matching and important terminologies related to pattern matching in instanceof.

What is Pattern matching?

A pattern is a combination of

a match predicate that determines if the pattern matches a target
a set of pattern variables that are conditionally extracted if the pattern matches the target.

A type test pattern consists of

a predicate that specifies a type
a single binding variable.

Before java 14 the instanceof operator was taking just a type now it is extended to take a type test pattern.

This is an example of an improved instanceof operator

if (obj instanceof String s) {
    ...
}

In this example the instanceof operator matches the target obj to the type test pattern as follows:

Check if obj is an instance of String
If the above check is true then cast obj to String and assigned to the binding variable s.

This is overall pattern matching for instanceof operator.

To understand this feature completely we will need to understand scoping rules for binding variable. Next section we will try to understand scoping rules.

Helpful flow sensitive scoping rules for instanceof binding variable

The scope is one of the best part of this language feature, the binding variable is available only where it is required. It makes code bug free.

To understand the scope of binding variable we will go through 3 examples.

Basic case
expression with short circuit && operator
expression with short circuit || operator

Basic case

Let’s take a look at the basic scenario, using following code example.

if (integer instanceof Number number) {
    System.out.println(number.intValue());
} else {
    System.out.println("Binding variable number not accessible here");
}

In this example, the instanceof operator “matches” the target number to the type test pattern as follows:

if the number is an instance of Number, then it is cast to Number and assigned to the binding variable number.
The binding variable is in scope of the true block of the if statement, and not in the false block of the if statement.

expression with short circuit && operator

Now we will take an example of a little complex expression short circuit && operator.

Object obj = "Name";
if (obj instanceof String s && s.length() > 3)
{
    System.out.println(s.charAt(1));
}
else
{
    System.out.println("s not accessible here");
}

Here in the above example s.length() will be called only when obj is instance of String. That’s why it makes sense to have s accessible on right-hand side of the short circuit operator as well. When both conditions in short circuit && operator are true, which also means s is a String, s is accessible in if block as well.

expression with short circuit || operator

This is an example with || operator, it has compilation error at s.length() and s.charAt(1)

if (obj instanceof String s || s.length() > 3)
{
    System.out.println(s.charAt(1));
}

Here when obj is String, it doesn’t need to evaluate the expression on the right side, so s not accessible on right side expression (s.length() > 3).
When obj is not String, it doesn’t get cast and then assigned to the binding variable. The binding variable s is not in scope on the right-hand side of the || operator, nor it is in scope in the true block, and we get compilation error.

At the end

Knowing language features like this helps you get the best java jobs, that’s why to help you I wrote ebook 5 steps to Best Java Jobs. Download this step by step guide for free!

Resources

https://openjdk.java.net/jeps/375, This is Java enhancement proposal for Pattern Matching for instanceof in JDK15.
https://github.com/Vipin-Sharma/JDK15Examples, this is link to code examples used in this post.
https://www.infoq.com/presentations/java-futures-2019/ , Presentation by Java Language Architect Brian Goetz.
https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

Jfeatures

Memory statistics for running Java application

Troubleshooting a running Java Application with jmap

jmap command

Java program we will be analyzing in this post

Printing class loader statistics of Java heap

Printing information on objects awaiting finalization

Printing histogram of java object heap

Taking Java process Heap dump

JDK16 feature Taking gzipped heap dump

Conclusion

Analyzing hung Java process

Troubleshooting a Java Application with jhsdb

jhsdb modes

Structure of commands

Java program we will be debugging in this post

Connecting jhsdb with Java process

Using pid to connect with a hanged process

Connecting jhsdb with core dump file

Starting debugd server and connecting using –connect option

Conclusion

Resources

What are my command-line flags, and the system properties for running Java process

Troubleshooting a Java Application with jinfo

Command structure

Java program we will be analyzing in this post

jinfo help command

Print command-line flags passed to the JVM

Print a particular command-line flag in running Java process

Print Java system properties as name-value pairs

Printing all 3, system properties, VM flags, and VM arguments

Update manageable VM flags

Conclusion

Find all the Java processes running on your machine

Troubleshooting a Java Application with jps

jps command

Java program we will be debugging in this post

Print Java process ids

Print process id along with the class name

Print Java process ids along with full package name

Print process ids along with class name and arguments passed to the main method.

Print JVM arguments passed to Java process

jcmd to list Java processes

Conclusion

Resources

Avoid multithreading bugs using immutable Java Records

Java language features making record immutable

Shallowly immutable

Conclusion

Resources

Java Records: Data carrier classes

Records

Common implementation use cases

Java code before and after Record

Record classes in detail

Restrictions on record

Constructors

Update on @Override annotation

Local record, enum, and interfaces are now allowed in Java

Inner class can declare static members

Why record, why not just tuples?

Conclusion

Resources

Debugging Java app without IDE

Troubleshoot java application with the jdb Utility

jdb command

Java program we will be debugging in this post

Attach jdb to Java application

debugging and monitoring

Conclusion

JCStress

What is JCStress

Starting with first JCStress test

Setting up a project and how to run JCStress test

More JCStress APIs

Using Result classes in JCStress

Arbiters

Signal

Nested tests

Shared Metadata

`jcmd` to list Java processes