Memory Allocation

In Java, all objects are dynamically allocated on the heap. This differs from languages like C++, where objects can be allocated on either the stack or the heap. When you use the new keyword in Java, the object is allocated on the heap, whereas in C++, objects can also be stack-allocated, unless they are declared globally or statically.

When you declare a variable of a class type in Java, memory for the object is not allocated immediately. Only a reference is created. To allocate memory to an object, the new keyword must be used. This ensures that objects are always allocated on the heap.

Creating a String Object in Java

There are two ways to create a string in Java:

1. By String Literal
2. By using the new Keyword

1. String Literal :  This is the most common way to create a string in Java, using double-quotes.

Example:

System.out.println("Hello");  // valid
system.out.println("Hello");  // invalid

In this case, every time a string literal is created, the JVM checks whether the string already exists in the string constant pool. If it does, a reference to the pooled instance is returned. If it doesn’t, a new string instance is created in the pool. Therefore, only one object will be created for both str1 and str2 if they have the same value.

The JVM is not obligated to create new memory if the string already exists in the pool.

2. Using the new Keyword : You can also create strings using the new keyword.

Example:

String str1 = new String("Hello");
String str2 = new String("Hello");

Here, both str1 and str2 are different objects. Even though the string content is the same, the JVM creates separate memory locations in the heap for each object when using the new keyword. The JVM will not check if the string already exists in memory; it always creates new memory for each object.

The JVM is forced to allocate new memory for each string object created using new.

Uninitialized Object Example

If you attempt to use a reference to an object without initializing it, Java will throw a compilation error, as the object does not have memory allocated to it.

Example with Error:

class Demo {
    void display() {
        System.out.println("Demo::display() called");
    }
}

public class Main {
    public static void main(String[] args) {
        Demo d;  // No memory allocated yet
        d.display();  // Error: d is not initialized
    }
}

Output:

Error: variable d might not have been initialized

Garbage Collection: Garbage Collection (GC) is a key feature in Java that enables automatic memory management. GC is responsible for reclaiming memory used by objects that are no longer needed, making that memory available for future use. To achieve this, the garbage collector monitors objects in memory, identifies those that are still referenced, and deallocates the memory for objects that are no longer in use. One common approach used by garbage collectors is the Mark and Sweep algorithm, which marks objects that are still reachable and then sweeps away the unmarked ones to free up memory.

Types of Garbage Collection in Java

The Java Virtual Machine (JVM) provides several garbage collection strategies, each affecting the application’s throughput and the pause time experienced during collection. Throughput measures how fast the application runs, while pause time indicates the delay introduced during garbage collection.

1. Serial Garbage Collector : The Serial Garbage Collector is the simplest form of GC, using a single thread to perform garbage collection. When this collector is in use, it stops all application threads during the collection process, known as stop-the-world behavior. Since it uses only one thread, it is not ideal for multi-threaded applications or environments where responsiveness is crucial. As a result, while it reduces complexity, it increases application pause time, negatively impacting throughput. This collector is suitable for smaller applications or single-threaded systems.

Usage:
To use the Serial Garbage Collector explicitly, execute your application with the following JVM argument:

java -XX:+UseSerialGC -jar MyApplication.jar

2. Parallel Garbage Collector : The Parallel Garbage Collector, also known as the Throughput Collector, is the default collector in Java 8. It improves upon the Serial Collector by using multiple threads to perform garbage collection, allowing for better throughput at the expense of longer pause times. Like the Serial Collector, it stops all application threads during the garbage collection process. However, it provides control over the number of threads the collector uses and allows you to specify maximum pause times.

Usage:
To run the Parallel Garbage Collector with a specified number of threads:

java -XX:+UseParallelGC -XX:ParallelGCThreads=<num_of_threads> -jar MyApplication.jar

To limit the maximum pause time for the GC, you can set the following parameter:

java -XX:+UseParallelGC -XX:MaxGCPauseMillis=<max_pause_ms> -jar MyApplication.jar

3. CMS Garbage Collector (Concurrent Mark-Sweep) : The Concurrent Mark-Sweep (CMS) Garbage Collector attempts to minimize application pauses by performing most of its work concurrently with the application. It scans memory for unreferenced objects and removes them without freezing the entire application, except in two specific scenarios:

• When there are changes in heap memory during the garbage collection process.
• When marking referenced objects in the old generation space.

CMS typically uses more CPU than the Parallel Collector to achieve better application responsiveness. It is ideal for applications that can afford to allocate additional CPU resources for lower pause times. To enable the CMS Garbage Collector, use the following command:

Usage:

java -XX:+UseConcMarkSweepGC -jar MyApplication.jar

4. G1 Garbage Collector (Garbage-First): Introduced in Java 7 and made the default in Java 9, the G1 Garbage Collector was designed for applications that require large heap sizes (greater than 4GB). Instead of treating the heap as a monolithic memory block, G1 divides it into equal-sized regions. During garbage collection, G1 focuses on the regions with the most garbage, collecting them first, hence the name Garbage-First. Additionally, G1 compacts memory during garbage collection, reducing fragmentation and enhancing performance. This garbage collector offers significant performance benefits for larger applications, especially those running on modern JVMs.

Usage:

If you’re using a Java version earlier than 9 and want to enable the G1 Garbage Collector, specify the following JVM argument:

java -XX:+UseG1GC -jar MyApplication.jar

5. Example with G1 Garbage Collector: Let’s update the example to demonstrate the use of the G1 Garbage Collector. In this scenario, we’ll manage memory for a simple Employee class.

class Employee {
    private int id;
    private String name;
    private int age;
    private static int nextId = 1;

    public Employee(String name, int age) {
        this.name = name;
        this.age = age;
        this.id = nextId++;
    }

    public void display() {
        System.out.println("ID: " + id + "\nName: " + name + "\nAge: " + age);
    }

    public void displayNextId() {
        System.out.println("Next employee ID will be: " + nextId);
    }

    @Override
    protected void finalize() throws Throwable {
        --nextId;
        System.out.println("Finalize called for employee ID: " + id);
    }
}

public class TestEmployee {
    public static void main(String[] args) {
        Employee emp1 = new Employee("Alice", 30);
        Employee emp2 = new Employee("Bob", 25);
        Employee emp3 = new Employee("Charlie", 35);

        emp1.display();
        emp2.display();
        emp3.display();

        emp1.displayNextId();
        emp2.displayNextId();
        emp3.displayNextId();

        {
            // Temporary employees
            Employee tempEmp1 = new Employee("David", 28);
            Employee tempEmp2 = new Employee("Eva", 22);

            tempEmp1.display();
            tempEmp2.display();

            tempEmp1.displayNextId();
            tempEmp2.displayNextId();

            // Making temp employees eligible for GC
            tempEmp1 = null;
            tempEmp2 = null;

            // Requesting garbage collection
            System.gc();
        }

        emp1.displayNextId();  // After GC, nextId should be updated correctly
    }
}

Output:

ID: 1
Name: Alice
Age: 30
ID: 2
Name: Bob
Age: 25
ID: 3
Name: Charlie
Age: 35
Next employee ID will be: 4
Next employee ID will be: 4
Next employee ID will be: 4
ID: 4
Name: David
Age: 28
ID: 5
Name: Eva
Age: 22
Next employee ID will be: 6
Next employee ID will be: 6
Finalize called for employee ID: 4
Finalize called for employee ID: 5
Next employee ID will be: 4

In C, programmers have full control over the allocation and deallocation of dynamically created objects. If a programmer neglects to free memory for unused objects, this results in memory leaks.

In Java, automatic garbage collection helps to manage memory, but there can still be scenarios where objects remain uncollected because they are still referenced. If an application creates a large number of objects that are no longer in use but are still referenced, the garbage collector cannot reclaim their memory. These unnecessary objects are referred to as memory leaks. If the memory allocated exceeds the available limit, the program may terminate with an OutOfMemoryError. Therefore, it is crucial to ensure that objects no longer needed are made eligible for garbage collection. Tools can also help in detecting and managing memory leaks, such as:

• HP OVO
• HP JMeter
• JProbe
• IBM Tivoli

Example of a Memory Leak in Java

import java.util.ArrayList;

public class MemoryLeakExample {
    public static void main(String[] args) {
        ArrayList<Object> list1 = new ArrayList<>(1000000);
        ArrayList<Object> list2 = new ArrayList<>(100000000);
        ArrayList<Object> list3 = new ArrayList<>(1000000);
        System.out.println("Memory Leak Example");
    }
}

Output:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

In Java, when a new thread is created, the JVM assigns a separate stack for it. The memory for this stack does not need to be contiguous. The JVM performs two primary operations on this stack: it pushes and pops frames, and this stack can be referred to as the runtime stack. For each thread, every method invocation is stored in this runtime stack, which includes parameters, local variables, intermediate results, and other related data. After the method completes execution, the respective entry is removed from the stack. When all method calls finish, the stack becomes empty, and the JVM removes the empty stack just before terminating the thread. Each stack’s data is thread-specific, ensuring that the data within a thread’s stack is not accessible to other threads. Hence, local data in this stack is considered thread-safe. Each entry in the stack is known as a Stack Frame or Activation Record.

Stack Frame Structure

The stack frame consists of three key parts:

1. Local Variable Array (LVA)
2. Operand Stack (OS)
3. Frame Data (FD)

When the JVM invokes a Java method, it first checks the method’s class data to determine the required size of the local variable array and operand stack, measured in words. It then creates a stack frame of the appropriate size and pushes it onto the Java stack.

1. Local Variable Array (LVA): The local variable array is organized as a zero-based array of slots where each slot stores a 4-byte word.

• It stores all parameters and local variables of a method.
• Values of types int, float, and object references each occupy 1 slot (4 bytes).
• double and long values occupy 2 consecutive slots (8 bytes total).
• byte, short, and char values are converted to int before being stored.
• Most JVM implementations allocate 1 slot for boolean values.

The parameters of a method are placed into the local variable array in the order they are declared. For instance, consider a method in the Example class:

class Example {
    public void bike(int i, long l, float f, double d, Object o, byte b) {
        // Method body
    }
}

The local variable array for the bike() method would store each parameter in order.

2. Operand Stack (OS): The JVM uses the operand stack as a workspace for storing intermediate results from computations.

• It is also structured as an array of words, similar to the local variable array, but the operand stack is accessed through specific instructions that push and pop values.
• Certain instructions push values onto the operand stack, others perform operations on them, and some instructions pop the results back into the local variable array.

Example of Operand Stack Usage:

The following assembly instructions illustrate how the JVM might subtract two integers stored in local variables and store the result in another local variable:

iload_0    // Push the value of local variable 0 to the operand stack
iload_1    // Push the value of local variable 1 to the operand stack
isub       // Subtract the two values on the operand stack
istore_2   // Pop the result and store it in local variable 2

3. Frame Data (FD): Frame data contains symbolic references and data related to method returns.

• It includes a reference to the constant pool and handles normal method returns.
• Additionally, it stores references to the exception table, which helps locate the correct catch block in case an exception is thrown during execution.

In summary, the stack frame in Java is structured to efficiently manage method calls, local variables, intermediate operations, and exception handling, providing a safe and organized environment for method execution within each thread.