Java 8 memory management .

                                                                

 Java   8  improved   JVM   memory  management   and  garbage  collection . The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace; similar to the  JRockit and IBM JVM's.

  First   of all    we need to understand  why  we  need to  improve  JVM  for better

 Memory  management  . 

·       Fixed size at start-up – difficult to tune.

·       Internal Hotspot types were Java objects : Could move with full GC, opaque, not strongly typed and hard to debug, needed meta-metadata.

·       Simplify full collections : Special iterators for metadata for each collector

·       Want to deallocate class data concurrently and not during GC pause

·       Enable future improvements that were limited by PermGen.

The Permanent Generation (PermGen) space has completely been removed and is kind of replaced by a new space called Metaspace. The consequences of the PermGen removal is that obviously the PermSize and MaxPermSize JVM arguments are ignored and you will never get a java.lang.OutOfMemoryError: PermGen error.

Advantages of MetaSpace

·       Take advantage of Java Language Specification property : Classes and associated metadata lifetimes match class loader’s

·       Per loader storage area – Metaspace

·       Linear allocation only

·       No individual reclamation (except for RedefineClasses and class loading failure)

·       No GC scan or compaction

·       No relocation for metaspace objects

Now we  can  look   meta space  properties .

Metaspace capacity

• By default class metadata allocation is limited by the amount of available native memory (capacity will of course depend if you use a 32-bit JVM vs. 64-bit along with OS virtual memory availability).

• A new flag is available (MaxMetaspaceSize), allowing you to limit the amount of native memory used for class metadata. If you don’t specify this flag, the Metaspace will dynamically re-size depending of the application demand at runtime.

Metaspace garbage collection

• Garbage collection of the dead classes and classloaders is triggered once the class metadata usage reaches the “MaxMetaspaceSize”.
• Proper monitoring & tuning of the Metaspace will obviously be required in order to limit the frequency or delay of such garbage collections. Excessive Metaspace garbage collections may be a symptom of classes, classloaders memory leak or inadequate sizing for your application.

Java heap space impact

• Some miscellaneous data has been moved to the Java heap space. This means you may observe an increase of the Java heap space following a future JDK 8 upgrade.

Metaspace monitoring

• Metaspace usage is available from the HotSpot 1.8 verbose GC log output.
• Jstat & JVisualVM have not been updated at this point based on our testing with b75 and the old PermGen space references are still present.

-->