A nieve approach to Java would be that it's considered greedy when it comes to memory. You allocate and dedicate the memory instead of sharing it. This allocation of memory is stored within something called a java heap (Like a big bucket to hold memory). The memory you've allocated together with other hardware + software components from the OS constructs something called a Java virtual Machine (JVM). (As the name states, a JVM a virtual machine that can be located your computer or server)

Of course this is by design. With the constant demand of memory allows the JVM to execute applications without the worry of other applications sucking the computer resources. You can configure how much memory to allocate by using the values -Xms (the initial allocation of memory) and -Xmx (the maximum amount it can store in it's java heap). As java is an object orientated program, it creates objects. These objects require memory. Java will allocate memory to the objects from the JVM heap (or in other words, the java heap from the JVM).

Question is, what happens to the memory that it's been allocated? Well, the object still retains the memory and continues to do so even if the object is now idling or referenced by other objects. So what happens when new objects need that memory that the idle object was initially allocated? This is where the Garbage Collection comes into play. When around 80% of the memory has been allocated, the garbage collector will start and release any memory allocated to idling objects and place this back into the java heap.

It's a nice approach on managing objects though what happens if the memory cannot be released by simple garbage collection? The solution here is to do a full garbage collection by suspending the JVM and cleaning up everything. This is by design and may not cause a problem if JVM has not been allocated enough memory. The full garbage collector will occur more frequently and continue to suspend the JVM prolonging it's required tasks.

Applying the JVM too much memory is also a problem because even though it's happy doing it's thing, it will eventually get to that 80% threshold and will then require a simple garbage collection though this time round a simple cleanup will be much longer comb-through when releasing memory . Eventually the garbage collector will execute a full cleanup thus leaving the JVM suspended for much longer.

So the challenge here is to determine how much memory is needed to start -Xms without applying too much memory -Xmx.

Another terminology that is often used out of context is Java Memory Leaks. Referring back to the garbage collection topic, imagine a poorly-designed java code which creates new objects within a never ending loop. If this is the case, it will create an infinite amount of object and continue to hand out memory for each of these objects. If the object is still in use, the garbage collector cannot assist by releasing the memory which will eventually leave the JVM without any available memory and eventually eventually come to a complete halt.

There's a well constructed java article on how to fix memory leaks in java. At the moment this isn't by biggest concern as I'm measuring java memory and not memory leaks though I would recommend you having a quick read.

Imagine an application server which needed to load a very large number of classes just for the startup phase. It would be illogical to allocate it a huge amount of memory to the heap size for just 1 effort. Instead, the JVM will retrieve this additional memory from outside the heap and from the OS - this is called the PermGen Size thus allowing the JVM to execute large 1-time efforts. This issue will occur if the OS is unable to provide any free memory to the JVM.

The thumb in the air rule is that you should have the PermSize a quarter the size of the MaxHeapSize.