All auto variables and runtime allocation during processing will be stored in the stack memory segment. The garbage collector deallocates the memory after use. So, there is no manual memory management process associated with the stack memory.

However, extensive use of auto variables also may cause memory errors. This is the reason we have already discussed why minimizing unnecessary auto variable declarations is necessary.

Stack memory is also used to execute program instructions. Each instruction is broken down into a single operation and put into a stack by the interpreter. Then, a recursive procedure is used to execute all the instruction stacks and return the result.

Let's have a look at how stack memory works for objects and primitives:

public class ExampleClass
{
  public ExampleClass()
  {
    int bitMapCount = 0;  // primitive type
    Bitmap testBmp = BitmapFactory.decodeFile("bitmap path"); // Object loading
    bitMapCount = 1;
  }
}

In this example, bitMapCount is an int local variable and gets stored in the stack directly. The memory used for this variable will be freed just after the scope.

However, testBmp is a bitmap object, which will be allocated in the heap, but the reference will be stored in the stack. When the program pointer comes out of the scope, the reference will be automatically deleted, and the garbage collector can identify the heap memory allocated for testBmp as having zero reference and will free this memory segment.

Heap memory is the segment where all the instances of classes and arrays are stored. JVM allocates this memory while instantiating any object.

The garbage collector does not operate automatically on this memory segment during application runtime. It is the developer's responsibility to free the memory after use. In the case of Android, the garbage collector will only free the memory when there is no reference for the memory segment in the running application.

Game assets are the major elements that are stored in this memory segment. Art is the most significant asset among them. So, optimizing bitmaps has a direct impact on heap memory uses. Very often, the developer allocates memory for assets and does not break the reference. This causes the memory block to be occupied during the entire runtime.

Here is an example:

// create a bitmap in a class constructor having global
// scope with public access
public class ExampleClass
{
  public Bitmap testBmp;
  public ExampleClass()
  {
    testBmp = BitmapFactory.decodeFile("bitmap path");
  }
}

In this example, the memory for the bitmap will be occupied even after the use, until the ExampleClass instance is there in memory. The interpreter has no standing instruction to free the memory segment, because testBmp still has the reference to the memory allocated to the bitmap.

We can optimize this in the following way with a bit of modification:

public class ExampleClass
{
  public Bitmap testBmp;
  public ExampleClass()
  {
    testBmp = BitmapFactory.decodeFile("bitmap path");
  }
  // create a method to free memory allocated for the
  // bitmap after use
  public void unloadBitmap()
  {
    testBmp = null;
  }
}

In this case, by calling unloadBitmap() after the use of the bitmap will remove the reference of the loaded bitmap from testBmp. So, the garbage collector will find this memory location as zero-referenced memory and free it to be used for other allocations.

In the case of Android development, the developer must not worry about register memory. Registers are directly associated with the processor, and the processor stores the most significant and frequently used data in this memory segment.

Register memory is the fastest memory segment used for any application runtime.