Java VM PermGen space

The Java VM memory is split up to 3 memory spaces:

• The Java Heap. Applicable for all JVM vendors, usually split between YoungGen (nursery) & OldGen (tenured) spaces.
• The PermGen (permanent generation). Applicable to the Sun HotSpot VM only (PermGen space will be removed in future Java 7 or Java 8 updates)
• The Native Heap (C-Heap). Applicable for all JVM vendors.

The Java HotSpot VM permanent generation space is the JVM storage used mainly to store your Java Class objects.  The Java Heap is the primary storage that is storing the actual short and long term instances of your PermGen Class objects.

The PermGen space is fairly static by nature unless using third party tool and/or Java Reflection API which relies heavily on dynamic class loading.

It is important to note that this memory storage is applicable only for a Java HotSpot VM; other JVM vendors such as IBM and Oracle JRockit do not have such fixed and configurable PermGen storage and are using other techniques to manage the non Java Heap memory (native memory).

Below diagram showcases various heap memories and how we can configure them using vm arguments.

Understanding how the JVM uses native memory on Windows

http://www.ibm.com/developerworks/java/library/j-nativememory-linux/

JVM: Permgen is a non-heap

In Oracle's JVM, the permanent generation is not part of the heap. It's a separate space for class definitions and related data. In Java 6 and earlier, interned strings were also stored in the permanent generation. In Java 7, interned strings are stored in the main object heap.

http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html

From above link, we can understand these terms:

Eden Space (heap): The pool from which memory is initially allocated for most objects.

Survivor Space (heap): The pool containing objects that have survived the garbage collection of the Eden space.

Tenured Generation (heap): The pool containing objects that have existed for some time in the survivor space.

Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.

Code Cache (non-heap): The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.

one more article on this @ https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation

Finding java process id's

Go to command prompt and type jps, this will provide the currently running java process id's in your system.

Troubleshooting Memory Leaks

http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/memleaks.html

Meaning of OutOfMemoryError

One common indication of a memory leak is the java.lang.OutOfMemoryError error. This error is thrown when there is insufficient space to allocate an object in the Java heap or in a particular area of the heap. The garbage collector cannot make any further space available to accommodate a new object, and the heap cannot be expanded further.

When the java.lang.OutOfMemoryError error is thrown, a stack trace is printed also.

A java.lang.OutOfMemoryError can also be thrown by native library code when a native allocation cannot be satisfied, for example, if swap space is low.

An early step to diagnose an OutOfMemoryError is to determine what the error means. Does it mean that the Java heap is full, or does it mean that the native heap is full? To help you answer this question, the following subsections explain some of the possible error messages, with reference to the detail part of the message:

• Exception in thread "main": java.lang.OutOfMemoryError: Java heap space
  See 3.1.1 Detail Message: Java heap space.
• Exception in thread "main": java.lang.OutOfMemoryError: PermGen space
  See 3.1.2 Detail Message: PermGen space.
• Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit
  See 3.1.3 Detail Message: Requested array size exceeds VM limit.
• Exception in thread "main": java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?
  See 3.1.4 Detail Message: request <size> bytes for <reason>. Out of swap space?.
• Exception in thread "main": java.lang.OutOfMemoryError: <reason> <stack trace> (Native method)
  See 3.1.5 Detail Message: <reason> <stack trace> (Native method).

Sizing the Java heap

Size your Java heap so that your application runs with a minimum heap usage of 40%, and a maximum heap usage of 70%.

Introduction

An incorrectly sized Java heap can lead to OutOfMemoryError exceptions or to a reduction in the performance of the Java application.
If the Java heap is smaller than the memory requirements of the application, OutOfMemoryError exceptions are generated because of Java heap exhaustion. If the Java heap is slightly larger than the requirements of the application, garbage collection runs very frequently and affects the performance of the application.
You must correctly size the Java heap based on the real memory usage of the Java application.

Sizing the heap based on application memory utilization

Set the maximum Java heap size, using the -Xmx command-line option, to a value that allows the application to run with 70% occupancy of the Java heap.
The Java heap occupancy often varies over time as the load applied to the application varies. For applications where occupancy varies, set the maximum Java heap size so that there is 70% occupancy at the highest point, and set the minimum heap size, using the -Xms command line option, so that the Java heap is 40% occupied at its lowest memory usage. If these values are set, the Java memory management algortihms can modify the heap size over time according to the application load, while maintaining usage in the optimal area of between 40% and 70% occupancy.

Maximum possible heap size and maximum recommended heap size (32-bit Java)

The memory space provided by the operating system to the Java process varies by operating system and is used for two separate memory areas: the Java heap and the native heap. Because a finite amount of memory is provided by the operating system, and that memory is shared between the two heaps, the larger the amount of memory that is allocated to the Java heap, using the -Xmx setting, the smaller the native heap becomes. If the native heap is too small, an OutOfMemoryError occurs when it is exhausted, in the same way as for the Java heap.

Platform	Additional options	Maximum heap size	Recommended heap size limit	Additional notes
AIX	None	3.25 GB	2.5 GB	Maximum heap size is not required to be, but should ideally be, a multiple of 256 MB
Linux	None	2 GB	1.5 GB
	Hugemem Kernel	3 GB	2.5 GB
Windows	None	1.8 GB	1.5 GB
	/3GB	1.8 GB	1.8 GB

The table shows both the maximum Java heap possible and a recommended limit for the maximum Java heap size setting. The use of a maximum Java heap setting up to the recommended limit is unlikely to reduce the native heap size to a point that the native heap is exhausted.
Before setting a Java heap size greater than the recommended limit, you must understand the level of usage of the native heap, to ensure that the native heap does not become exhausted.
If you are running an application that has particularly high numbers of threads or makes heavy use of Java Native Interface (JNI) code, for example, Type 2 JDBC drivers, you might experience problems relating to the native heap with smaller Java heap sizes than the recommended limit.

Maximum possible heap size and maximum recommended heap size (64-bit Java)

When running 64-bit Java, the memory space provided by the operating system to the Java process is very large. You can therefore assume that no limit is imposed on the maximum size of the Java heap because of the contention of memory resource between the Java heap and the native heap.

Java heap size and amount of physical memory available

It is important to have more physical memory than is required by all of the processes on the machine combined to prevent paging or swapping. Paging reduces the performance of the system and affects the performance of the Java memory management system.
When increasing the Java heap size, ensure that enough unused physical memory is available on the machine to cover the increase. If sufficient physical memory is not available, either install additional memory or take into account the effect on overall performance that occurs.
This requirement does not apply to operating systems running on System z.

Size your Java heap so that your application runs with a minimum heap usage of 40%, and a maximum heap usage of 70%.

http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000139b8b453-11951f1e7ff-8000_1001.html

Memory Limits for Windows Releases

http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx

Physical Memory Limits: Windows 8

The following table specifies the limits on physical memory for Windows 8.

Version	Limit on X86	Limit on X64
Windows 8 Enterprise	4 GB	512 GB
Windows 8 Professional	4 GB	512 GB
Windows 8	4 GB	128 GB

Physical Memory Limits: Windows 7

The following table specifies the limits on physical memory for Windows 7.

Version	Limit on X86	Limit on X64
Windows 7 Ultimate	4 GB	192 GB
Windows 7 Enterprise	4 GB	192 GB
Windows 7 Professional	4 GB	192 GB
Windows 7 Home Premium	4 GB	16 GB
Windows 7 Home Basic	4 GB	8 GB
Windows 7 Starter	2 GB	N/A