While learning about java memory profiling, I keep seeing the term "perm space" in addition to "heap." I know what the heap is - what's perm space?
It stands for permanent generation:
The permanent generation is special
because it holds meta-data describing
user classes (classes that are not
part of the Java language). Examples
of such meta-data are objects
describing classes and methods and
they are stored in the Permanent
Generation. Applications with large
code-base can quickly fill up this
segment of the heap which will cause
java.lang.OutOfMemoryError: PermGen no
matter how high your -Xmx and how much
memory you have on the machine.
Perm space is used to keep informations for loaded classes and few other advanced features like String Pool(for highly optimized string equality testing), which usually get created by String.intern() methods.
As your application(number of classes) will grow this space shall get filled quickly, since the garbage collection on this Space is not much effective to clean up as required, you quickly get Out of Memory : perm gen space error. After then, no application shall run on that machine effectively even after having a huge empty JVM.
Before starting your application you should java -XX:MaxPermSize to get rid of this error.
Simple (and oversimplified) answer: it's where the jvm stores its own bookkeeping data, as opposed to your data.
Perm Gen stands for permanent generation which holds the meta-data information about the classes.
Suppose if you create a class name A, it's instance variable will be stored in heap memory and class A along with static classloaders will be stored in permanent generation.
Garbage collectors will find it difficult to clear or free the memory space stored in permanent generation memory. Hence it is always recommended to keep the permgen memory settings to the advisable limit.
JAVA8 has introduced the concept called meta-space generation, hence permgen is no longer needed when you use jdk 1.8 versions.
The permgen space is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects.
It holds stuff like class definitions, string pool, etc. I guess you could call it meta-data.
Permgen space is always known as method area.When the classloader subsystem will load the the class file(byte code) to the method area(permGen).
It contains all the class metadata eg: Fully qualified name of your class, Fully qualified name of the immediate parent class, variable info, constructor info, constant pool infor etc.
What exists under PremGen : Class Area comes under PremGen area. Static fields are also developed at class loading time, so they also exist in PremGen. Constant Pool area having all immutable fields that are pooled like String are kept here. In addition to that, class data loaded by class loaders, Object arrays, internal objects used by jvm are also located.
PermGen Space stands for memory allocation for Permanent generation All Java immutable objects come under this category, like String which is created with literals or with String.intern() methods and for loading the classes into memory. PermGen Space speeds up our String equality searching.
JVM has an internal representation of Java objects and those internal representations
are stored in the heap (in the young generation or the tenured generation).
JVM also has an internal representation of the Java classes and those
are stored in the permanent generation
Related
Would the data in the following statement be stored as automatic memory allocation, or dynamic memory allocation or both
myFunction(new MyClass());
Thank You!
The terms “automatic memory allocation” and “dynamic memory allocation” make no sense in the context of Java. In Java, all memory is managed by the execution environment.
In other programming languages, the terms “automatic storage” and “dynamic storage” are used to distinguish between storage, which is automatically deallocated when going out of scope, and storage, which requires an explicit deallocation action performed by the application. In Java, there are no explicit deallocations at all. You will find that people and literature continue to distinguish between stack and heap, where only the latter contains objects, whose lifetime may exceed the execution of the method in which they were created. This, however, is only a logical separation, which might not reflect how a particular JVM implementation actually works.
The Java® Language Specification doesn’t mandate much details about the workings of this. There are only two spots at all:
15.12.4.5. Create Frame, Synchronize, Transfer Control
A method m in some class S has been identified as the one to be invoked.
Now a new activation frame is created, containing the target reference (if any) and the argument values (if any), as well as enough space for the local variables and stack for the method to be invoked and any other bookkeeping information that may be required by the implementation (stack pointer, program counter, reference to previous activation frame, and the like). If there is not sufficient memory available to create such an activation frame, a StackOverflowError is thrown.
17.4.1. Shared Variables
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields, and array elements are stored in heap memory. In this chapter, we use the term variable to refer to both fields and array elements.
Local variables (§14.4), formal method parameters (§8.4.1), and exception handler parameters (§14.20) are never shared between threads and are unaffected by the memory model.
Note that this is the only place where the term “heap” is used as memory type and how it’s actually defined here…
The sections §15.9.4. Run-Time Evaluation of Class Instance Creation Expressions and §15.10.2. Run-Time Evaluation of Array Creation Expressions are much more vague, saying that “space is allocated” and an OutOfMemoryError is thrown if not enough space is available, and nothing more.
So if you go the route of distinguishing between stack and heap, you can say that your code myFunction(new MyClass()); will cause a heap allocation for an instance of MyClass, followed by a stack allocation for the activation frame of the actual implementation of the myFunction method. Not that it matters for any practical purpose.
If you want to dig more into the way, JVMs may implement it, you may refer to the Java® Virtual Machine Specification instead:
2.5.2. Java Virtual Machine Stacks
Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6). A Java Virtual Machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java Virtual Machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java Virtual Machine stack does not need to be contiguous.
2.5.3. Heap
The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.
The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous
Note, how these definitions only differ in their purpose while not having significant difference in their constraints, i.e. might be fixed-size or resizable and might be contiguous or not, not to speak of the explicit mentioning of the possibility to allocate stack frames on the heap.
There are three groups of memory in Java
Heap - this is where Objects are created and located when you call new MyClass();
Stack - The stack contains stack frames, and stack frames have space allocated for primitives and pointers to Objects in the Heap. Stack frames are allocated on method call and deallocated on method return
String constants: String literals defined at compile time will be added to a String constant pool. At runtime, it is possible to add strings to the pool using String.intern()
That's it
There are two things being allocated in your example;
The expression, new MyClass() allocates an instance of MyClass on the object heap.
The result of the new expression is an object reference. The object reference is saved in the activation record for a call to myFunction(). Activation records are allocated on the calling thread's call stack.
When you create a new object, it often allocated on the heap however with escape analysis, it can be unpacked onto the stack as if it was a local variable.
The only allocation is via new or a capturing lambda (or some native method in rare cases) There isn't any explicit distinction between different ways of allocating an object.
As shown in the image, Permgen is further divided into several parts.
Runtime constant pool stores constants pertaining to each type that is loaded by class loader.
Method area stores method information such as method return type, method name. (correct me if I am wrong here.)
And Reserved area is the part which is reserved if more memory is required by permgen.
But what I don't understand is, what is code area in the image? Any code is stored in this space(seems vague to me)?
Any code is stored in this space(seems vague to me)?
Any specific reason for that ?
The possible answer could be : Code area stores the byte code of the classes loaded into your memory.
But then the question comes, Why class is not loaded directly in RAM ?
Because we have a JVM to provide interoperability, Since JVM is an intermediary between java code and the machine , we need some place to store the code statements until JVM is scheduled by OS to execute its code.(for OS JVM is a process). So, It loads the byte code in Code area(if i am right) and when scheduled, further interprets code(.class) into underlying machine instructions.
The answer to me is "Code area holds the byte code of the classes".
To back the idea mentioned above ., here are some concepts copied as it is from Oracle blog which says:
So the Java classes are stored in the permanent generation. What all
does that entail? Besides the basic fields of a Java class there are:
Methods of a class (including the bytecodes)
Names of the classes (in the form of an object that points to a string also in the permanent generation)
Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).
Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).
Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
Information used for optimization by the compilers (JITs)
Hope it clears.
From an interesting article on the problems of PermGen: Will Java 8 Solve PermGen OutOfMemoryError?:
Jon Masamitsu, JVM developer at Oracle, explained 2006 in his blog the
purpose of the permanent generation: The permanent generation contains
information about classes, such as bytecode, names and JIT
information. It is stored in a separate space, because it is mostly
static and garbage collection can be much more optimized by separating
it.
Actually the PermGen store all your static code. i think this makes sense to you why there is a code area in PermGen.
I will venture to guess, based on the following article, by Jon Masamitsu, from which the following quote is taken, that the figure above is a misrepresentation (or rephrased - a misleading representation):
So the Java classes are stored in the permanent generation. What all
does that entail? Besides the basic fields of a Java class there are
Methods of a class (including the bytecodes)
Names of the classes (in
the form of an object that points to a string also in the permanent
generation)
Constant pool information (data read from the class file,
see chapter 4 of the JVM specification for all the details).
Object
arrays and type arrays associated with a class (e.g., an object array
containing references to methods).
Internal objects created by the JVM
(java/lang/Object or java/lang/exception for instance)
Information
used for optimization by the compilers (JITs)
The bytecode of all classes that have been resolved live in permgen. Just because a library has 1.2MB of classes doesn't they will be loaded by the JVM from the JAR. It it possible, even likely, that only a small fraction of those classes are used by a particular application.
You can run many large application servers whose sum total JAR size is >1GB using only 64MB permgen, because only a fraction of the classes are ever used.
Also take this example:
class A {
// ... code
}
class B {
void method1() {
// something
}
void method2() {
A a = new A();
}
}
While these classes may reside in the same JAR, merely creating an instance of B does not cause class A to be loaded. If you never call method2(), class A will never be loaded by the JVM. Additionally, contrary to popular belief, permgen can be garbage collected, and if space gets low, and there are no instances on the heap referring to class A anymore, then class A can be removed from permgen.
If I create a static variable in Java, does it automatically go into the perm gen space on the heap? it seems obvious that the answer is yes, but i cannot find the confirmation anywhere.
I know the static variable (also strings and enums) are alive for the life of the JVM so it must go on the permanent heap. IS this correct?
The idea of the "PermGen" is completely implementation-dependent, and JVMs are free to handle the "physical" memory management however makes sense to them--they're not even actually required to provide garbage collection!
The PermGen is just a feature of some JVM implementations (including the Sun/Oracle HotSpot JVM for many years), and it's actually being eliminated with a new approach in the Oracle Java 8 JVM. It's quite likely that JVMs that include the concept of a PermGen will put static variables there for performance, but it's entirely up to the programmer.
JLS #17.4.1 Shared Variables
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields and array elements are stored in heap memory. In this chapter, we use the term variable to refer to both fields and array elements. Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model.
Nice description here By #Stephen:static allocation in java - heap, stack and permanent generation
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
static allocation in java - heap, stack and permanent generation
its a small confusion...defining static to class, methods and variables.In this three cases where thus the memory allocated. ? My boss is familiar with C,he says only variables are in heap memory and rest (static classes and static methods) will remain in main memory. is that ture? any explanation.?
one more
in android using static class and static methods is a best practice ?
Try this,
static members are stored in Method Area.
Class instances and arrays are stored in heap memory. Heap memory is also called as shared memory. As this is the place where multiple threads will share the same data.
Non-heap Memory
It comprises of ‘Method Area’ and other memory required for internal processing. So here the major player is ‘Method Area’.
Method Area
As given in the last line, method area is part of non-heap memory( A special heap area). It stores per-class structures, code for methods and constructors. Per-class structure means runtime constants and static fields.
The above three (heap memory, non-heap memory and method area) are the main jargon when it comes to memory and JVM.
Class instances and arrays are stored in heap memory. Heap memory is also called as shared memory. As this is the place where multiple threads will share the same data.
Static variables are saved in the same place as the Classes declaration (methods and attributes, etc). 1). Classes (loaded by the classloaders) go in a special area on heap called Permanent Generation, and static field too go to the same place as they are common to each instance of the class.
For more details :
see this answer
In Java,
String literals in String Constant Pool are not garbage collected,
since they are referenced from Table of references which is created by instance of runtime in order to optimize space.
If Size of String literal pool exceeds then,
Since each String in String literal pool has reference hence it will be not eligible for GC.
how it is handled by JVM ?
There is a long discussion with real code examples at JavaRanch.
The general output is the following:
If a string is added to constant pool at RUNTIME using String.intern(), it can be garbage collected after it is no longer in use. Most probably, the string pool keeps only soft references to added strings, thus allowing to garbage collect them (can't be sure, because String.intern() is a native method).
If a string is a COMPILE time constant, it is added to the constant pool of the corresponding class. Therefore, it can be garbage collected only after the class is unloaded.
The answer to your question is: the only way how you can get OutOfMemoryError because of String constants is to load lot's of classes with many string literals computed at compile time. Then you can eventually exceed maximum size of PermGen space. But this will happen at the time you load classes into memory (e.g., start your application, deploy project to a WebServer, dynamically load new library, etc.)
String literals can be collected when they are no longer needed. Usually this is not a problem if they appear in classes because there are other limits you are likely to reach if you attempt to load lots of classes e.g. Maximum Perm Gen.
Generally speaking, developers are smart enough not to over use the string literal pool and instead using databases or file to load the bulk of their data if its a non trivial size.
You can introduce a problem if you use String.intern() a lot in an attempt to optimise the space of your system. String.intern() is not free and becomes increasingly expensive if you add a large number (millions) of string into it. If this is a performance problem, it should be reasonably obvious to the developer when it is.