PermGen Vs Metaspace

As you saw in Java 8 PermGen space has been decommission. In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace.

I recommend that you read the PermGen removal summary and comments from Jon on this subject. 

In summary:

PermGen space situation

• This memory space is completely removed.
• The PermSize and MaxPermSize JVM arguments are ignored and a warning is issued if present at start-up.

Metaspace memory allocation model

• Most allocations for the class metadata are now allocated out of native memory.
• The klasses that were used to describe class metadata have been removed.

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.

How to set the Metaspace in Java 8

There are some new flags added for Metaspace in JDK 8:

• -XX:MetaspaceSize=

where is the initial amount of space(the initial high-water-mark) allocated for class metadata (in bytes) that may induce a garbage collection to unload classes. The amount is approximate. After the high-water-mark is first reached, the next high-water-mark is managed by the garbage collector

• -XX:MaxMetaspaceSize=

where is the maximum amount of space to be allocated for class metadata (in bytes). This flag can be used to limit the amount of space allocated for class metadata. This value is approximate. By default there is no limit set.

• -XX:MinMetaspaceFreeRatio=

where is the minimum percentage of class metadata capacity free after a GC to avoid an increase in the amount of space (high-water-mark) allocated for class metadata that will induce a garbage collection.

• -XX:MaxMetaspaceFreeRatio=

where is the maximum percentage of class metadata capacity free after a GC to avoid a reduction in the amount of space (high-water-mark) allocated for class metadata that will induce a garbage collection.

permgen vs metaspace in java 8

As you may be aware in Java 8, one of its feature is removal of Permanent Generation (PermGen).
In this post, we will see how and for what the PermGen was being used till java 7 and its successor in java 8

A Java memory problem such as java.lang.OutOfMemoryError: PermGen space is one of the most frequent and complex problems a Java EE application support person can face with a production system. This article is one of the post that will focus on a particular OOM flavour: PermGen space depletion of a Java HotSpot VM.

Parameter used: -XXPermSize=1024m

before we see more details about it lets see a memory model in java:

 

Primary objective is to revisit the fundamentals of the permanent generation space and to teach you how to identify a particular pattern of PermGen space problem and possible causes of PermGen memory leak.

 

java.lang.OutOfMemoryError: PermGen space patterns

Find below some of the most common patterns of OutOfMemoryError due to the depletion of the PermGen space.

Pattern	Symptoms	Possible root cause scenarios	Resolution
OOM observed during or after a migration of a Java EE server to newer version	- OOM may be observed on server start-up at deployment time - OOM may be observed very shortly after server start-up and after 1 or 2+ hours of production traffic	- Higher PermGen capacity is often required due to increased Java EE server vendor code and libraries	- Increase your PermGen space capacity via -XX:MaxPermSize
OOM observed after a certain period of time	- OOM observed after a longer but consistent period of time (days) - PermGen space monitoring will show hourly or daily increase during your application business hours	- There are many possible causes of PermGen space memory leak. The most common is a class loader leak: increasing number of Class objects overtime - Improper JVM arguments like usage of the Xnoclassgc flag (turn OFF Class garbage collection)	- Review your JVM HotSpot start-up arguments for any obvious problem like Xnoclassgc flag - Analyse the JVM HotSpot Heap Dump as it can provides some hints on the source of a class loader leak - Investigate any third party API you are using for any potential class loader leak defect - Investigate your application code for any improper use of Reflection API and / or dynamic class loading
OOM observed following a redeploy of your application code (EAR, WAR files...)	- OOM may be observed during or shortly after your application redeploy process	- Unloading and reloading of your application code can lead to PermGen leak (class loader leak) and deplete your PermGen space fairly quickly	- Open a ticket with your Java EE vendor for any known class loader leak issue - Shutdown and restart your server (JVM) post deployment to cleanup any class loader leak

  

 

 

In next part we will see more details about metaspace introduced in java 8 as a successor of PermGen.

Logging levels in Log4j

As promised in previous blog, I have collected some information about log levels and its configurations.

There are mainly eight log level's available in log4j.

ALL, TRACE, DEBUG , INFO, WARN, ERROR, FATAL, OFF

  TRACE is used for finer-grained informational events than the DEBUG.

We can define more than log levels in our applications but one per appender. Following is a simple example of how it look like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

import org.apache.log4j.*; public class LogClass { private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class); public static void main(String[] args) { log.setLevel(Level.WARN); log.trace("Trace Message!"); log.debug("Debug Message!"); log.info("Info Message!"); log.warn("Warn Message!"); log.error("Error Message!"); log.fatal("Fatal Message!"); } }

# Define the root logger with appender file
log = /usr/home/log4j
log4j.rootLogger = WARN, FILE

# Define the file appender
log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=${log}/log.out

# Define the layout for file appender
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.conversionPattern=%m%n

Now if we compile and run the above program and we will get following result in /usr/home/log4j/log.out file.

Warn Message!
Error Message!
Fatal Message!

 If someone needs more information do add a comment, I will try to provide that information as well.


Happy reading and keep adding comments. cheers..!