Java Threads and Locks

Thread - a light weighted set of instructions that forms the execution logic of an algorithm.
Java has few types of Threads managed by JVM process
    - Application Threads
    - JVM internal threads (GC threads, code generation and code optimizer threads, Finalizer threads)

And, each Java thread has its own Stack space (which can also be set to a specific value using -Xss)

One more interesting thing is 'locks'. When threads share a resource, the resource must be controlled by using the 'synchronized' or wait, notify keywords. The synchronization happens with the use of 'locks'. Each thread must hold a lock on an object it is working.

There are four different kinds of locks:
Fat locks: A fat lock is a lock with a history of contention (several threads trying to take the lock simultaneously), or a lock that has been waited on (for notification).
Thin locks: A thin lock is a lock that does not have any contention.
Recursive locks: A recursive lock is a lock that has been taken by a thread several times without having been released.
Lazy locks: A lazy lock is a lock that is not released when a critical section is exited. Once a lazy lock is acquired by a thread, other threads that try to acquire the lock have to ensure that the lock is, or can be, released. Lazy locks are used by default in Oracle JRockit JVM 27.6. In older releases, lazy locks are only used if you have started the JVM with the -XXlazyUnlocking option.

Threads while in the process of acquiring locks, goes in to two states - Spinning and Sleeping. Spinning is a state where the thread continuously checks on a lock whether it is released or not. While Sleeping is a state where the thread passively checks for a lock is released or not. The first state eats up CPU while seconds state yields CPU to other threads.

Now, we have seen Threads and the Locks, lets see one more interesting thing - Lock Chains!

Threads forms lock chains if they are queuing up to obtain a lock while the head is holding the lock for its actions. If there are long lock chains then the applications threads are spending long times in waiting mode there by resulting in long latencies.

And, there are three types of lock chains - Open, Deadlocked, Blocked.

Open is a simple lock chain where the head thread is holding a lock which is needed for the threads that are in the chain.
Deadlock chain is two threads waiting on each other. As it is a circular wait, there is no head in this lock chain.
Blocked chain is an extension hanging from any of the above two cases. Any more threads waiting on a thread which is either in an open chain or in a deadlock chain.

JRockit JVM GC Types

Below mentioned are the types of GCs used by JRockit JVM

Mark and Sweep GC

Marks all reachable objects from Java Threads, native Handles and other root sources. Sweeps all the remaining objects.

Works on entire heap if no Nursery implemented. If nursery is there then YGC will be used for Nursery and M&S will be for Old space.

So YGCs happens more frequently and Old GCs happens less frequently and then Full GCs happens much less frequently.

During sweep, the free slots of memory are identified in order to allocate for new objects

Mark and Sweep can be of multiple types
    (1) Mostly Concurrent Mark ans sweep
    (2) Parallel Mark and Sweep

    In combination - Concurrent Mark and Parallel Sweep, Parallel Mark and concurrent sweep

The above method1 allows most of the time to have Java Threads running (except in the initial marking)
Method2 will be very fast as it uses all CPUs and also stops Threads



Generational GC
If Nursery is implemented then the young GC algorithm called Generational Garbage Collection is used. And, the young GC happens parallel there by stopping the Threads while cleaning up and moving the objects to older space


Dynamic and Static GC:
Dynamic is the default mode of JRockit JVM which is basically an automatic selection of GC strategy to use. We can set the Dynamic mode like 'Throughput', 'Pausetime', 'Deterministic' based on the need and application type

One more interesting concept is the compaction. While sweeping the memory, the old GC algorithm also does compaction similar to defragmentation. This helps in object allocation faster and efficient Heap usage.

JRockit JVM Heap

Below flow chart tries to illustrate the JRockit JVM's object allocation to Heap and the garbage collection process.

Full GC happens when the old space is running out of room for moving the senior object from young space.

Apart from Heap, JVM also have external memory to hold Java methods, thread stacks and native handles are allocated in memory separate from the heap, as well as JVM internal data structures.

Just In Time

JIT - Just In Time   

A famous phrase to say to someone who just arrives when there is a reference.

JRockit JVM uses JIT in similar way - compiles the method calls (byte code to Machine code) just in time i.e. when the method is called
JVM with JIT is like a 4 stroke engine - picks up slowly but cruises afterwards. Similarly, with JIT, application start up may be a bit slow initially as there will lot of method call in the initial run phase of the application there by JIT taking time to compile the byte code to machine code and then JVM calls the machine code directly there by crusing on the machine code instructions.

And then, there comes some more intelligence with JRockit JVM - The cruise control ! - The Optimization.

JVM monitors the threads and looks for the methods that require some optimization, like the most frequently used methods ('HOT' methods). Once these are identified, the optimizations will be done in the background which is basically boosting these 'Hot' methods execution by eliminating duplicate code logic, reducing number of costly references (like local variable vs. object method calls) etc.,

On the other side, often JIT is blamed when ever there is a slow start of JVM and the application.To validate this, we can do some simple checks like

(1) Inserting timers in the application to measure application startup
(2) Starting the JVM with a command line option -Xverbose:codegen -- This gives the information about a method being compiled like name, memory location, duration of compilation, time since compilation started
(3) Check the initial heap(-Xms) and max heap (-Xmx) sizes. It is a good practice to have these two values the same. If these two are not the same and -Xms is too small then it forces JVM to do more inintial full GCs until it pushes the roof (commited bytes) towards reserved bytes (-Xmx). On the other hand if these two values are vey large then it takes time for JVM to reserve huge memory and then commit huge memory
(4) Record using JRA to analyse the JVM actions
(5) Sometimes the optimization process of JVM may also cause slowness.Try restarting JVM with -XnoOpt command and see the difference.
(6) And, try to eliminate those methods from optimization process which take too long for optimization by creating optfile and sending runtime diagnostics commands using JRCMD, Ctrl+Break, JRockit Management Console.

JRockit JVM and Xs commands

The non standard general JRockit specific commands are called X command line options
Otherwise called The awsome commands - I would say :)

-Xbootclasspath
-Xbootclasspath/a
-Xbootclasspath/p
-Xcheck:jni
-Xdebug
-Xgc
-XgcPrio (deprecated)
-XlargePages
-Xmanagement
-Xms
-Xmx
-XnoClassGC (deprecated)
-XnoOpt
-Xns
-XpauseTarget
-Xrs
-Xss
-XstrictFP
-Xverbose
-Xverbosedecorations
-XverboseLog
-XverboseTimeStamp
-Xverify

And, if you want experiment on JVM performance , there is entirely a different set of commands called the XXs



Reference:
http://docs.oracle.com/cd/E15289_01/doc.40/e15062/optionxx.htm#g1067276

The WOW tools for JRockit JVM

Have you ever faced problems with your Java applications and want to drill down through JVM ? Are you dreaming to write tools to monitor JVM ?
Here are the set of tools called JRockit Mission Control - the advanced super tools to monitor and manage, profile and diagnose your apps running on JRockit  JVM in non intrusive way - goodbye JVMTI

The three important tools of JR MC are
The Management Console         
The JRockit Runtime Analyzer
The Memory Leak Detector


Management console is a JMX monitoring and management console similar to JConsole.

JRA is like a java app and JVM profiler - A handy tool for every JVM performance engineer. It records the JVM behavior and with the help of JRA mission control plugin, lot of analysis can be done including digging information about synchronization problems, GC, OS, memory analysis, method call stack, lock information and more interestingly the CPU bound computational latencies as well !!

And the MLD is a cool tool to detect memory leaks online ! move away from tiresome offline comparative huge heap dump analysis.