JAVA MEMORY MANAGEMENT

In every programming language, the memory is a vital resource and is also scarce in nature.
Hence it’s essential that the memory is managed thoroughly without any leaks.Allocation and
deallocation of memory is a critical task and requires a lot of care and consideration.

However in Java, unlike other programming language, the JVM and to be specific Garbage
Collector has the role of managing memory allocation so that the programmer needs not to.
Whereas in other programming languages such as C the programmer has direct access to the
memory who allocates memory in his code, thereby creating a lot of scope for leaks.

The major concepts in Java Memory Management :

 JVM Memory Structure
 Working of Garbage Collector

Java Memory Structure:

JVM defines various run time data area which are used during execution of a program. Some of the
areas are created by the JVM whereas some are created by the threads that are used in a program.
However, the memory area created by JVM is destroyed only when the JVM exits. The data areas
of thread are created during instantiation and destroyed when the thread exits.

Heap :
  It is a shared runtime data area and stores the actual object in a memory. It is
instantiated during the virtual machine startup.
 This memory is allocated for all class instances and array. Heap can be of fixed or
dynamic size depending upon the system’s configuration.
 JVM provides the user control to initialize or vary the size of heap as per the
requirement. When a new keyword is used, object is assigned a space in heap, but the
reference of the same exists onto the stack.
 There exists one and only one heap for a running JVM process.

Scanner sc = new Scanner(System.in);

The above statement creates the object of Scanner class which gets allocated to heap whereas
the reference ‘sc’ gets pushed to the stack.
Note: Garbage collection in heap area is mandatory.

Method Area:

 It is a logical part of the heap area and is created on virtual machine startup.
 This memory is allocated for class structures, method data and constructor field data,
and also for interfaces or special method used in class. Heap can be of fixed or dynamic
size depending upon the system’s configuration.
 Can be of a fixed size or expanded as required by the computation. Needs not to be
contiguous.
Note: Though method area is logically a part of heap, it may or may not be garbage collected even
if garbage collection is compulsory in heap area.

JVM Stacks:

 A stack is created at the same time when a thread is created and is used to store data and
partial results which will be needed while returning value for method and performing
dynamic linking.
 Stacks can either be of fixed or dynamic size. The size of a stack can be chosen
independently when it is created.
 The memory for stack needs not to be contiguous.

Native method Stacks:

Also called as C stacks, native method stacks are not written in Java language. This memory is
allocated for each thread when its created. And it can be of fixed or dynamic nature.

Program counter (PC) registers:

Each JVM thread which carries out the task of a specific method has a program counter register
associated with it. The non native method has a PC which stores the address of the available JVM
instruction whereas in a native method, the value of program counter is undefined. PC register is
capable of storing the return address or a native pointer on some specific platform.
Working of a Garbage Collector:
JVM triggers this process and as per the JVM garbage collection process is done or else withheld. It
reduces the burden of programmer by automatically performing the allocation or deallocation of
memory.
Garbage collection process causes the rest of the processes or threads to be paused and thus is costly
in nature. This problem is unacceptable for the client but can be eliminated by applying several
garbage collector based algorithms. This process of applying algorithm is often termed as Garbage
Collector tuning and is important for improving the performance of a program.
Another solution is the generational garbage collectors that adds an age field to the objects that are
assigned a memory. As more and more objects are created, the list of garbage grows thereby
increasing the garbage collection time. On the basis of how many clock cycles the objects have
survived, objects are grouped and are allocated an ‘age’ accordingly. This way the garbage collection
work gets distributed.
In the current scenario, all garbage collectors are generational, and hence, optimal.

Note: System.gc() and Runtime.gc() are the methods which requests for Garbage collection to
JVM explicitly but it doesn’t ensures garbage collection as the final decision of garbage
collection is of JVM only.
PARAMETRES TO CHOOSE GARBAGE COLLECTION ALGORITHMS -
Much as GC shields us from manual memory management, it achieves this at a cost. We should aim
to keep the GC runtime overhead as low as possible. There are several variables that can help us
decide which collector would best serve our application needs. We'll go over them in the remainder of
this section.
Heap Size
This is the total amount of working memory allocated by the OS to the JVM. Theoretically, the larger
the memory, the more objects can be kept before collection, leading to longer GC times. The
minimum and maximum heap sizes can be set using -Xms=<n> and -Xmx=<m> command-line
options.
Application Data Set Size
This is the total size of objects an application needs to keep in memory to work effectively. Since all
new objects are loaded in the young generation space, this will definitely affect the maximum heap
size and, hence, the GC time.
Number of CPUs
This is the number of cores the machine has available. This variable directly affects which algorithm
we choose. Some are only efficient when there are multiple cores available, and the reverse is true for
other algorithms.
Pause Time
The pause time is the duration during which the garbage collector stops the application to reclaim
memory. This variable directly affects latency, so the goal is to limit the longest of these pauses.
Throughput
By this, we mean the time processes spend actually doing application work. The higher the
application time vs. overhead time spent in doing GC work, the higher the throughput of the
application.
Memory Footprint
This is the working memory used by a GC process. When a setup has limited memory or many
processes, this variable may dictate scalability.
Promptness
This is the time between when an object becomes dead and when the memory it occupies is
reclaimed. It's related to the heap size. In theory, the larger the heap size, the lower the promptness as
it will take longer to trigger collection.
Java Version
As new Java versions emerge, there are usually changes in the supported GC algorithms and also the
default collector. We recommend starting off with the default collector as well as its default
arguments. Tweaking each argument has varying effects depending on the chosen collector.
Latency
This is the responsiveness of an application. GC pauses affect this variable directly.
GARBAGE COLLECTORS
Besides serial GC, all the other collectors are most effective when there's more than one core
available:
1.Serial GC
The serial collector uses a single thread to perform all the garbage collection work. It's selected by
default on certain small hardware and operating system configurations, or it can be explicitly enabled
with the option -XX:+UseSerialGC.
Pros:
Without inter-thread communication overhead, it's relatively efficient.
It's suitable for client-class machines and embedded systems.
It's suitable for applications with small datasets.
Even on multiprocessor hardware, if data sets are small (up to 100 MB), it can still be the most
efficient.
Cons:
It's not efficient for applications with large datasets.
It can't take advantage of multiprocessor hardware.
2. Parallel/Throughput GC
This collector uses multiple threads to speed up garbage collection. In Java version 8 and earlier, it's
the default for server-class machines. We can override this default by using the -XX:+UseParallelGC
option.
Pros:
It can take advantage of multiprocessor hardware.
It's more efficient for larger data sets than serial GC.
It provides high overall throughput.
It attempts to minimize the memory footprint.
Cons:
Applications incur long pause times during stop-the-world operations.
It doesn't scale well with heap size.
It's best if we want more throughput and don't care about pause time, as is the case with non-
interactive apps like batch tasks, offline jobs, and web servers.
3. Concurrent Mark Sweep (CMS) GC
We consider CMS a mostly concurrent collector. This means it performs some expensive work
concurrently with the application. It's designed for low latency by eliminating the long pause
associated with the full GC of parallel and serial collectors.
We can use the option -XX:+UseConcMarkSweepGC to enable the CMS collector. The core Java
team deprecated it as of Java 9 and completely removed it in Java 14.
Pros:
It's great for low latency applications as it minimizes pause time.
It scales relatively well with heap size.
It can take advantage of multiprocessor machines.
Cons:
It's deprecated as of Java 9 and removed in Java 14.
It becomes relatively inefficient when data sets reach gigantic sizes or when collecting humongous
heaps.
It requires the application to share resources with GC during concurrent phases.
There may be throughput issues as there's more time spent overall in GC operations.
Overall, it uses more CPU time due to its mostly concurrent nature.
4. G1 (Garbage-First) GC
G1 uses multiple background GC threads to scan and clear the heap just like CMS. Actually, the core
Java team designed G1 as an improvement over CMS, patching some of its weaknesses with
additional strategies.
In addition to the incremental and concurrent collection, it tracks previous application behavior and
GC pauses to achieve predictability. It then focuses on reclaiming space in the most efficient areas
first — those mostly filled with garbage. We call it Garbage-First for this reason.
Since Java 9, G1 is the default collector for server-class machines. We can explicitly enable it by
providing -XX:+UseG1GC on the command line.
Pros:
It's very efficient with gigantic datasets.
It takes full advantage of multiprocessor machines.
It's the most efficient in achieving pause time goals.
Cons:
It's not the best when there are strict throughput goals.
It requires the application to share resources with GC during concurrent collections.
G1 works best for applications with very strict pause-time goals and a modest overall throughput,
such as real-time applications like trading platforms or interactive graphics programs.
5. Z Garbage Collector (ZGC)
ZGC is a scalable low latency garbage collector. It manages to keep low pause times on even multi-
terabyte heaps. It uses techniques including reference coloring, relocation, load barriers and
remapping. It is a good fit for server applications, where large heaps are common and fast application
response times are required.
It was introduced in Java 11 as an experimental GC implementation. We can explicitly enable it by
providing -XX:+UnlockExperimentalVMOptions -XX:+UseZGC on the command line. For more
detailed descriptions, please visit our article on Z Garbage Collector.