The beauty of Spring is that it can integrates well with most of the prevailing popular technologies, and in the case of ORM, it integrates well with Hibernate.
I have written a Spring Book and in Chapter 8 i explain Spring’s Data Access capabilities in detail. There is separate topics written on ORM integration and this specific heading namely “Spring and Hibernate” is dedicated for explaining this beautiful integration between two open-source framework.
This section of the chapter examines the means by which Spring can be integrated with Hibernate. I assume that the reader is somewhat familiar with Hibernate and by reading this far familiar with Spring Framework as well to some extend.
ORM is a piece of software/product for the representation and conversion of data between the database and the object-oriented programming language. Hibernate is a powerful technology for persisting data and is a clear winner in the ORM race as of now. However it hasn’t become a standard. It takes much of the database related boiler-plate code from the developers, thereby asking the developers to concentrate on the core business logic of the application and not with the error-prone SQL syntax. It also enables application to access data from any database in a platform-independent manner.
One of the problems with using Hibernate is that the client Application that accesses the database using Hibernate Framework has to depend on the Hibernate APIs. These objects will continue to get scattered across the code throughout the Application. Above all, the application code has to manually maintain and manage these objects. Here comes Spring to the rescue with its IoC container capable of configuring these objects using Spring configurations.
For a beginner, this will be one of the question which they might have. For an expert even though this is well known jar file in Java, very few will know as to what it is and why it is so important. This blog post is a very short post, just giving some details of what rt.jar is and what constitutes Java as a whole (JDK/JRE).
rt.jar contains all the RunTime classes that comprise the Java SE platform’s core API’s. In simple terms this is the jar which contains classes like java.lag.String, java.io package etc. The source code for these API’s can be found in src.zip file in JAVA_HOME.
Since all the classes in the rt.jar are known to the JVM, these classes tend to be left alone with various checks that JVM does while loading these classes onto it. This is also done for various performance reasons. These jars are loaded by primodial class loaders and that’s the reason these classes avoid the basic security checks which the JVM does for other jars/classes.
The base files and folders in the JDK/JRE is shown in the below figure.
Image Courtesy – docs.oracle.com
For more details on all the various files and directories comprising JDK and JRE, i would suggest going through the official Oracle documentation as follows:
While i was reading the latest Java Magazine (July-August 2013), i came across a topic namely, “Adaptive Size Policy” with regards to one of the important components in JVM, garbage collection.
I researched on this topic and this blog post is my attempt to explain this in some details with good references for follow up reading.
Before going on to explain “Adaptive Size Policy”, i need to cover certain basics in the field of garbage collection. I will be covering this blog under such sub-topic for easy understanding and reading.
JVM Heap in General
JVM heap, aka heap, is divided into two regions, called as generation, namely
The Young generation region is further divided into sub-regions, namely
Survivor Space 1
Survivor Space 2
This is how it works when an object is created:
The object will be created in Eden and it could be destroyed there itself
If the Eden region is full, the object is pushed to Survivor Space 1
If the Survivor space 1 is full, the object is pushed to Survivor Space 2
The objects which are not destroyed in Survivor Space 2 are retired to the Old Generation region of the heap
To tweak the heap size commonly used Java options as -Xms and -Xmx. You can get a complete list of -X commands that you can use with respect to Java Heap Size, please run the command java -X. Below screenshot shows the various commends that can be used.
Java Garbage Collection in General
Most of the programming language including Java has a very important feature of automatic memory management, also known as “Garbage Collection”. Objects created during execution of a program, at various stages becomes unreachable and are considered as “garbage”. Over a period of time for managing memory, these garbage is removed and the space is regained for useful staff. Java has very good garbage collection and over a period of time, with some very good engineers working on it, using various algorithms, have made significant progress and enhancement this all important feature.
The core component in the Java SE platform is JVM (Java Virtual Machine). In the case of Oracle JVM, its called as “Oracle’s Hotspot JVM”. We will discuss garbage collection with respect to this Hotspot JVM as GC (Garbage Collection) methodologies differ according to the JVM being used.
Garbage collection is one of the biggest benefit which the Java language provides. If used in a proper manner it will be really beneficial, but if not used cautiously, it can doom your application big time. Some of the considerations with respect to garbage collection which have to be kept in mind are the following:
JVM Pause – The time taken by the JVM to do the GC during which the JVM pauses
Throughput – The time interval between successive GC
Our goal as an application tuner is to minimize the JVM pause and maximize throughput. There is no hard and fast rule that you can reply on to do this. It comes with experience and the environment in which your JVM/application functions, which will interfere to a greater extend.
There are various GC modes which are possible to be configured using various JVM commend line options. Having said that, these JVM options configured is dependent on various components like the hardware you are running, JVM version etc. to name a few. The default GC mode also depends on the JVM vendor. The various GC modes with respect to Hotspot JVM is as detailed below:-
As the name suggests it is executed by a single thread and requires a complete stop on all the processes carried out by JVM during the execution. The JVM switch for this is specified as -XX:+UseSerialGC
As the name suggests the collection is parallelized between multiple threads. This also requires the entire JVM operations to be stopped/deferred but during to parallelism, the time required will be reduced to a greater extend. The JVM switch for this is specified as -XX:+UseParallelGC. In modern days due to availability of multicore/multiprocessor this has become more of a norm.
Parallel Old GC
Incremental advancement over Parallel GC mode. I don’t want to go into much more detail, as this post is a head start for beginners to get a primer on GC. The JVM switch for this is specified as -XX:+UseParallelOldGC
Adaptive Size Policy
A special mode of Parallel Scavange in which the JVM automatically adapts and adjust the various heap sizes and does the GC. Might sound a big scary as you might feel that there isn’t much control in overall space allocation by JVM. But IMHO, the java engineers have put lots of effort and experience building this and they shouldn’t be taken as complete wrong and we should have fairly good confidence in using this switch as well. The JVM switch for this is specified as -XX:+UseAdaptiveSizePolicy
Concurrent Mark Sweep (CMS)
Its a low pause collector and the way by which it handles this by using different algorithms for collecting the various heap regions. The JVM switch for this is specified as -XX:+UseConcMarkSweepGC
CMS incremental mode
In this the CMS competes with the CPU cores to perform the GC. The GC thread and application thread works in parallel and in modern day hardware IMHO this is good option. The JVM switch for this is specified as -XX:+CMSIncrementalMode
G1 Garbage Collector
New generation collection mode introduced as part of JVM 1.6. For more details you can find the link to a blog by Alexey Ragozin. The JVM switch for this is specified as -XX:+UseG1GC
Adaptive Size Policy in Detail
Now coming to the main point in this blog, “Adaptive Size Policy”. Since now you have a good idea of the various basics with respect to JVM Heap and JVM GC options, I would be able to explain this concept much easily.
By defining adaptive size policy in a JVM, you are commanding the JVM to adapt itself to the surrounding environment by dynamically re-sizing the heap and its regions so as to attain certain goals already set as follows:
Minimize the footprint created by the heap
Adhere to the maximum garbage collection JVM pause as desired
Adhere to the minimum garbage collection throughput goal as desired
As detailed in the earlier section, to enable this set the JVM switch as follows:
To set the desired policy values, you can use the following switches:
-XX:MxGCPauseMillis=nnn – Tells the VM that maximum of nnn milliseconds on less is desired
-XX:GCTimeRatio=nnn – The ratio of GC time to application time
Ideally if you specify the -Xms value to be equal to -Xmx, adaptive size policy is nullified. In cases this might be desirable, but in most of the cases believing the engineers behind this algorithm will surely make your application perform faster and in no case IMHO this should be done whereby a feature is nullified as good amount of research and experience is employed while designing and developing it.
Its good to not that options beginning with -X are non-standard, means, need not be supported by all the VM vendors in the market and these are subject to change according to vendor discretion. The options beginning with -XX are non-stable and similar to -X, these are subject to change without notice.