Also, how does having a static variable affect things? (If at all) For example:
class MyClass{
static int[][] data;
static {
data = new int[some number][some number]; /*read data into array*/
}
static void run() {
/*now use data here*/
}
}
Is this put on the heap? Comparing that example with
class MyClass{
static void run() {
int[][] data = new int[some number][some number];
/*now use data here*/
}
}
How much difference is there between these two code examples? Please shed any insight.
Java has a concept of PermGen space - this is the space used to store all class definitions, static variables, interned strings, etc.
here is link
This Java heap memory is structured again into regions, called generations. The longer an object lives, the higher the chance it will be promoted to an older generation. Young generations(such as Eden on Sun JVM) are more garbage collected than older generations(survivor and tenured on Sun JVM). However, there is also some separate heap space called permanent generation. Since it is a separate region, it is not considered part of the Java Heap space. Objects in this space are relatively permanent. Class definitions are stored here, as are static instances.
A full description of PermGen space can also be found here, although note that this is changing with Java 8: here is link
Static variables are stored there, dynamically allocated things are stored in the regular heap.
(Note that even for the static array the things placed within the array are dynamically generated).
Your second example is better for this case though unless you really need to remember the contents of that array between calls. You are using up memory all the time to store an array that you only need while you are inside the method. Additionally by having the static data like that your method is not re-entrant. That means that if two threads call the method at the same time then they will interfere with each other and give bad results.
Every object, that you create while your program is running, is created in the heap space. I think this is the most important thing to understand, when you are asking for antyhing "better".
A variable can be a local variable inside a method (method parameters are also local in this sense), or they belong to an instance or to a class. Here is the difference. The memory for local variables is allocated on the thread's stack, the memory for instance and class variables reside in the corresponding object's space, which is in the heap.
Keep in mind, that variables only store references to objects. They do not store the object! Therefore the memory consumption of variables is very low.
There are just two places where data can reside in JVM: the heap and the stack (well, JNI tricks inclusive it can reside anywhere, but this is an exception). All local variables in methods are located on the stack, everything else - on the heap. In both your examples array data is allocated on the heap, though in the second example the reference maze is a method local variable so is itself located on the stack.
One thing you must carefully distinguish is the following:
placement of the reference-typed variable;
placement of the referent (the array in your case).
If I follow your thoughts correctly, you are not really interested in 1., which is just four bytes, but in 2.
If the variable which refers to the array is static, the array will be placed on the heap;
if the variable is local, and if the JIT compiler can prove that your array will definitely not be reachable when your solve method completes, then there is a chance that the whole array will be stack-allocated.
For arrays, which are quite large, but efficiently allocated objects, it will make very little difference where they are allocated—as long as they don't get tenured into the Old Generation. If they do get tenured regularly, then you will probably experience significant slowdowns due to frequent Full GC cycles.
Related
When I create new object for String builder and use that variable then how memory allocation work and what is result of my code snippet my sample code is
1)
String nextPoint=new StringBuilder().append("My").append("next").append("point").toString();
System.out.println(nextPoint);
2)
StringBuilder downPoint=new StringBuilder().append("My").append("next").append("point");
System.out.println(downPoint.toString());
Which variables/instance can consume memory?? which solution is better when i'm using "nextPoint" varaible or "downPoint" variable?
Which variables/instance can consume memory?
Every class occupies memory. How much depends on the class. Every object occupies heap memory. How much depends on its class. Many classes and objects also contain references to other objects, and those other objects occupy their own heap memory. Some objects also have associated native resources, which occupy an idiosyncratic amount of memory. Local variables occupy stack memory appropriate for their type, though under some circumstances certain local variables may share the same stack memory as others.
In your case (1):
String nextPoint=new StringBuilder().append("My").append("next").append("point").toString();
System.out.println(nextPoint);
variable nextPoint is a local reference variable, consuming stack memory (for a reference, not a whole String). It is initialized by creating a new StringBuilder object (on the heap) and appending three Strings to it (each one an object occupying heap memory), and then creating a new String object (also occupying heap memory), and storing a reference to it in nextPoint. The StringBuilder will have some kind of associated storage for the accumulated character data; this will not overlap that of any of the Strings involved.
Your case (2) differs only in that a reference to the StringBuilder is retained instead of a reference to the generated String. That may have implications for code that follows, but it makes no difference to which objects are created and what memory is needed.
which solution is better when i'm using "nextPoint" varaible or "downPoint" variable?
It depends on what you want to do afterward. If you're not going to use either of those variables again then the difference is purely stylistic.
what is result of my code snippet [?]
Put it in a class, run it, and find out for yourself. Or figure it out from the code. This one is not something you should need us to answer for you.
Both snippets do the same sequence of method calls, being
new StringBuilder().append("My").append("next").append("point").toString(),
so their memory usage is (mostly) the same. Only snippet (1) stores a reference to the StringBuilder in a variable, and (2) stores the resulting String reference. But as references are the same size, no matter what the refer to, that results in the same number of bytes occupied.
As I read somewhere, memory is allocated when instances are created and a space is allocated from the heap. If it is right than when and how much exactly memory is allocated during instances and objects creation?
Variables declared within a method are stored within the stack, while the actual objects are stored on the heap. Consider
Integer a = new Integer(10);
In this example, an object of type Integer is created on the heap and a reference (either 32 or 64bits) is returned and stored within the methods stack as variable 'a'. The JVM is free to keep variables like this within the CPU registers if it prefers as an optimization.
Memory of an object is allocated when the new keyword is used. It is usually assigned within the TLAB (thread local allocation buffer) which is part of the eden heap reserved to the running thread. Thus reducing the overheads of object allocation to a simple 'bump of a pointer'. The two times when the TLAB is not used, is 1) when the object is too large for the space remaining, inwhich case it will be promoted straight to the old gen and 2) when a supporting JVM decides via escape analysis that it can avoid the object entirely and allocate directly on to the stack (or even break the object apart and only assign the fields required on the stack).
The amount of memory reserved consists of an object header, usually 2 words (3 for an array) and then space for each of the fields declared in the object and its parent classes. The total size of those fields depends on the JVM and the underlying platform (eg 32 bit or 64 bit) and JVM configuration such as compressed references.
------------------+------------------+------------------ +--------------------------
| mark word | klass pointer | array size (opt) | padding and fields |
------------------+------------------+-------------------+--------------------------
Asking the JVM for sizes is not officially supported, but EHCache sizeOf is a very good 'best guess' that uses knowledge of different JVMs and access to the underlying pointers via the use of Java Unsafe.
The starting place for understanding the size of each field is the size of primitives defined by the Java language, however this is only the minimum sizes as the JVM is designed to work with 32bits and so primitives smaller than this are often padded out to 32 bits. For example booleans.
The exact layout of the fields will vary by JVM, but they will tend to be grouped by the class that defines them starting from the root of the inheritence tree. For example, consider
and
The pictures above were taken from this very good blog post that describes the memory layout very well,
"create instance" has the same meaning as "use new to create new object".
In a normal case, heap memory will be allocated at the time you ask for a new object, but that is not set in stone: HotSpot can also determine that it is safe to allocate the object on the call stack (by the process of Escape Analysis). This is more efficient as it doesn't need any garbage collection.
How much memory is allocated is highly implementation-specific, only Java arrays are guaranteed to be "packed" (modulo a fixed overhead). Boolean arrays, though, are specified as occupying a byte per element.
I'm reading your question as: "Who actually allocates memory for an object - the new keyword or the constructor?" If that's the case, the answer is the new keyword.
Constructors are typically chained, meaning that at least two constructors will run when you're creating an instance. On the other hand, memory for an instance is allocated only once.
Also, the type of allocation is determined using analysis of the usage of the produced reference (escape analysis, for example). This means that the most obvious place for the allocation to happen is at the constructor call site (that is, the place of the new expression).
The size of the memory allocated is such that it can accomodate an instance of the type following the new keyword. That latter size (the size of an instance of a type) is
the aggregate size of the primitive types (int, float, double, etc) it consists of,
plus the aggregate size of the references to the reference types (class or interface instances) it consists of,
plus "secret" stuff embedded in instances so that Java features can work (like a virtual table pointer, to allow fast runtime resolution of virtual method calls)
plus possible padding between each of those (to align the various types to their optimal address number multiples in memory).
In any case, when you do T obj1 = new T(), where T is the name of a class:
Memory is allocated somewhere to accomodate a T instance.
The instance is constructed.
If the instance is successfully constructed, a reference to the instance is returned.
That reference is stored in the obj1 variable.
When you do R obj2 = new R(), a similar thing happens for the type R, and type R may have a different size than T.
But neither of these local variables contains the instance. They both contain a reference to their assigned object. (Thus, the variables themselves might even be of the same size, if all they have to do is store a memory address.)
As I read somewhere that memory is allocated when instances are created and a space is allocated from the heap.
yes you are right, until and unless new is called it's just a null reference that is pointing to nothing.
If it is right than when and how much exactly memory is allocated when instances and objects are created?
It depends on the size of the object.
Have a look at Primitive Data Types to know about their size.
In Java, what is the best way to determine the size of an object?
Read more...
Class Variables
When a number of objects are created from the same class blueprint, they each have their own distinct copies of instance variables. In the case of the Bicycle class, the instance variables are cadence, gear, and speed. Each Bicycle object has its own values for these variables, stored in different memory locations.
Sometimes, you want to have variables that are common to all objects. This is accomplished with the static modifier. Fields that have the static modifier in their declaration are called static fields or class variables. They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory. Any object can change the value of a class variable, but class variables can also be manipulated without creating an instance of the class.
https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html
I would like to know how to place a local variable in memory? In method1, do the variable take a place into memory, one time?
In method2, do the variable take a place after deleting old place in memory, for each time?
public void method1() {
Object obj = null;
for(.....) {
obj = come from other-->
}
}
public void method2() {
for(.....) {
Object obj = come from other-->
}
}
You have a local variables which may be in a register or once in memory.
You also have an object which the local variable references. This will be created on each iteration in both cases.
They are effectively the same, except I would prefer the second case if it is possible as it narrows the scope of the local variable.
Each method call is associated with Activation Record that is stored on a call stack. The activation record holds references to the memory blocks in heap corresponding to the method level variables. Once the method call returns to the caller, this activation record will be removed from the stack and the memory references are potentially available to be garbage-collected.
In your case,
the obj in the first method, it's reference is stored in the call stack and the actual memory is on the heap and this is done once per method call.
the obj in the for loop in the second method is created once for each iteration and goes out of scope at the end of each iteration. So, the reference and the memory on the heap are allocated for each iteration.
The local variables are usually (unless e.g. optimized away) kept on the stack memory. But they can only store primitive values or references. The referenced objects themselves are usually allocated on the heap (withstanding any JIT optimization).
See Stack based memory allocation (Wikipedia) vs. Heap based memory allocation (Wikipedia).
Storing values on the stack is very cheap. Similar to a function call, where you store the return pointer on the stack. It does not require much more than incrementing the stack pointer (and you can imagine that incrementing a dedicated CPU register is fast!)
The object itself is different. Note that theoretically, some java compiler or JIT might be able to optimize your second code better, because you indicate clearly that the value is not needed for the next iteration. (An even better compiler should be able to figure this out itself.)
In general, a modern compiler should produce the same machine code after optimization for both cases. (This may happen in the JIT compiler, so the Java bytecode may still show the difference).
Anyway: do not try to overoptimize by reusing local variables. Instead, write explicit code and let the compiler optimize. By using a fresh variable inside the loop, you make it explicit that it is not reused anywhere. This can prevent some programming errors!
I believe in both cases a new Object is created in memory for every iteration. It is up to the garbage collector to notice that there are no references to any but the most 'recent' Object.
Objects in method1 and method2 will be placed in heap, but java compiler perform Escape analysis for determination we need release this kind of object after method execution or not. Escape analysis is implemented in Java Standard Edition 6
For example:
class A {
static int i=0;
static int j;
static void method() {
// static k=0; can't use static for local variables only final is permitted
// static int L;
}
}
Where will these variables be stored in Java, in heap or in stack memory? How are they stored?
Static methods (in fact all methods) as well as static variables are stored in the PermGen section of the heap, since they are part of the reflection data (class related data, not instance related). As of Java 8 PermGen has been replaced by MetaSpace and as per JEP 122 it only holds meta-data while static fields are stored in the heap.
Note that this mostly applies to Oracle's Hotspot JVM and others that are based on it. However, not every JVM has PermGen or Metaspace like Eclipse OpenJ9.
Update for clarification:
Note that only the variables and their technical values (primitives or references) are stored in PermGen space.
If your static variable is a reference to an object that object itself is stored in the normal sections of the heap (young/old generation or survivor space). Those objects (unless they are internal objects like classes etc.) are not stored in PermGen space.
Example:
static int i = 1; //the value 1 is stored in the PermGen section
static Object o = new SomeObject(); //the reference(pointer/memory address) is stored in the PermGen section, the object itself is not.
A word on garbage collection:
Do not rely on finalize() as it's not guaranteed to run. It is totally up to the JVM to decide when to run the garbage collector and what to collect, even if an object is eligible for garbage collection.
Of course you can set a static variable to null and thus remove the reference to the object on the heap but that doesn't mean the garbage collector will collect it (even if there are no more references).
Additionally finalize() is run only once, so you have to make sure it doesn't throw exceptions or otherwise prevent the object to be collected. If you halt finalization through some exception, finalize() won't be invoked on the same object a second time.
A final note: how code, runtime data etc. are stored depends on the JVM which is used, i.e. HotSpot might do it differently than JRockit and this might even differ between versions of the same JVM. The above is based on HotSpot for Java 5 and 6 (those are basically the same) since at the time of answering I'd say that most people used those JVMs. Due to major changes in the memory model as of Java 8, the statements above might not be true for Java 8 HotSpot - and I didn't check the changes of Java 7 HotSpot, so I guess the above is still true for that version, but I'm not sure here.
Prior to Java 8:
The static variables were stored in the permgen space(also called the method area).
PermGen Space is also known as Method Area
PermGen Space used to store 3 things
Class level data (meta-data)
interned strings
static variables
From Java 8 onwards
The static variables are stored in the Heap itself.From Java 8 onwards the PermGen Space have been removed and new space named as MetaSpace is introduced which is not the part of Heap any more unlike the previous Permgen Space. Meta-Space is present on the native memory (memory provided by the OS to a particular Application for its own usage) and it now only stores the class meta-data.
The interned strings and static variables are moved into the heap itself.
For official information refer : JEP 122:Remove the Permanent Gen Space
Class variables(Static variables) are stored as part of the Class object associated with that class. This Class object can only be created by JVM and is stored in permanent generation.
Also some have answered that it is stored in non heap area which is called Method Area. Even this answer is not wrong. It is just a debatable topic whether Permgen Area is a part of heap or not. Obviously perceptions differ from person to person. In my opinion we provide heap space and permgen space differently in JVM arguments. So it is a good assumption to treat them differently.
Another way to see it
Memory pools are created by JVM memory managers during runtime. Memory pool may belong to either heap or non-heap memory.A run time constant pool is a per-class or per-interface run time representation of the constant_pool table in a class file. Each runtime constant pool is allocated from the Java virtual machine’s method area and Static Variables are stored in this Method Area.
Also this non-heap is nothing but perm gen area.Actually Method area is part of perm gen.(Reference)
This is a question with a simple answer and a long-winded answer.
The simple answer is the heap. Classes and all of the data applying to classes (not instance data) is stored in the Permanent Generation section of the heap.
The long answer is already on stack overflow:
There is a thorough description of memory and garbage collection in the JVM as well as an answer that talks more concisely about it.
It is stored in the heap referenced by the class definition. If you think about it, it has nothing to do with stack because there is no scope.
In addition to the Thomas's answer , static variable are stored in non heap area which is called Method Area.
As static variables are class level variables, they will store " permanent generation " of heap memory.
Please look into this for more details of JVM. Hoping this will be helpful
static variables are stored in the heap
When we create a static variable or method it is stored in the special area on heap: PermGen(Permanent Generation), where it lays down with all the data applying to classes(non-instance data). Starting from Java 8 the PermGen became - Metaspace. The difference is that Metaspace is auto-growing space, while PermGen has a fixed Max size, and this space is shared among all of the instances. Plus the Metaspace is a part of a Native Memory and not JVM Memory.
You can look into this for more details.
In real world or project we have requirement in advance and needs to create variable and methods inside the class , On the basis of requirement we needs to decide whether we needs to create
Local ( create n access within block or method constructor)
Static,
Instance Variable( every object has its own copy of it),
=>2. Static Keyword will be used with variable which will going to be same for particular class throughout for all objects,
e.g in selenium : we decalre webDriver as static => so we do not need to create webdriver again and again for every test case
Static Webdriver driver
(but parallel execution it will cause problem, but thats another case);
Real world scenario => If India is class, then flag, money would be same for every Indian, so we might take them as static.
Another example: utility method we always declare as static b'cos it will be used in different test cases.
Static stored in CMA( PreGen space)=PreGen (Fixed memory)changed to Metaspace after Java8 as now its growing dynamically
As of Java 8 , PermGen space is Obsolete. Static Methods,Primitives and Reference Variables are stored in Java MetaSpace. The actual objects reside in the JAVA heap. Since static methods never get out of reference they are never Garbage collected both from MetaSpace and the HEAP.
I have been lately reading a lot on memory allocation schemes in java, and there have been many doubts as I have been reading from various sources. I have collected my concepts, and I would request to go through all of the points and comment on them. I came to know that memory allocation is JVM specific, so I must say beforehand, that my question is Sun specific.
Classes (loaded by the classloaders) go in a special area on heap : Permanent Generation
All the information related to a class like name of the class, Object arrays associated with the class, internal objects used by JVM (like java/lang/Object) and optimization information goes into the Permanent Generation area.
All the static member variables are kept on the Permanent Generation area again.
Objects go on a different heap : Young generation
There is only one copy of each method per class, be the method static or non-static. That copy is put in the Permanent Generation area.
For non-static methods, all the parameters and local variables go onto the stack - and whenever there is a concrete invocation of that method, we get a new stack-frame associated with it.
I am not sure where are the local variables of a static method are stored. Are they on the heap of Permanent Generation ? Or just their reference is stored in the Permanent Generation area, and the actual copy is somewhere else (Where ?)
I am also unsure where does the return type of a method get stored.
If the objects (in the young generation) needs to use a static member (in the permanent generation), they are given a reference to the static member && they are given enough memory space to store the return type of the method,etc.
Thank you for going through this !
First, as should be clear to you by now that there are very few people who can confirm these answers from first hand knowledge. Very few people have worked on recent HotSpot JVMs or studied them to the depth needed to really know. Most people here (myself included) are answering based on things they have seen written elsewhere, or what they have inferred. Usually what is written here, or in various articles and web pages, is based on other sources which may or may not be definitive. Often it is simplified, inaccurate or just plain wrong.
If you want definitive confirmation of your answers, you really need to download the OpenJDK sourcecode ... and do your own research by reading and understanding the source code. Asking questions on SO, or trawling through random web articles is not a sound academic research technique.
Having said that ...
... my question is Sun specific.
At the time this question was asked, Sun Microsystems had ceased to exist. The question was therefore Oracle specific. AFAIK, all current (non-research) 3rd-party JVM implementations are either direct ports of an OpenJDK release or descended from another Sun/Oracle release.
The answers below apply to Oracle Hotspot and OpenJDK releases, and probably to most others as well ... including GraalVM.
1) Classes (loaded by the classloaders) go in a special area on heap : Permanent Generation.
Prior to Java 8, yes.
As of Java 8, the PermGen space has been replaced with Metaspace. Loaded and JIT-compiled classes now go there. PermGen no longer exists.
2) All the information related to a class like name of the class, Object arrays associated with the class, internal objects used by JVM (like java/lang/Object) and optimization information goes into the Permanent Generation area.
More or less, yes. I'm not sure what you mean by some of those things. I'm guessing that "internal objects used by JVM (like java/lang/Object)" means JVM-internal class descriptors.
3) All the static member variables are kept on the Permanent Generation area again.
The variables themselves yes. These variables (like all Java variables) will hold either primitive values or object references. However, while the static member variables are in a frame that is allocated in the permgen heap, the objects/arrays referred to by those variables may be allocated in any heap.
4) Objects go on a different heap : Young generation
Not necessarily. Large objects may be allocated directly into the tenured generation.
5) There is only one copy of each method per class, be the method static or non-static. That copy is put in the Permanent Generation area.
Assuming that you are referring to the code of the method, then AFAIK yes. It may be a little more complicated though. For instance that code may exist in bytecode and/or native code forms at different times during the JVM's life.
... For non-static methods, all the parameters and local variables go onto the stack - and whenever there is a concrete invocation of that method, we get a new stack-frame associated with it.
Yes.
... I am not sure where are the local variables of a static method are stored. Are they on the heap of Permanent Generation ? Or just their reference is stored in the Permanent Generation area, and the actual copy is somewhere else (Where ?)
No. They are stored on the stack, just like local variables in non-static methods.
6) I am also unsure where does the return type of a method get stored.
If you mean the value returned by a (non-void) method call, then it is either returned on the stack or in a machine register. If it is returned on the stack, this takes 1 or two words, depending on the return type.
7) If the objects (in the young generation) nees to use a static member (in the permanent generation), they are given a reference to the static member && they are given enough memory space to store the return type of the method,etc.
That is inaccurate (or at least, you are not expressing yourself clearly).
If some method accesses a static member variable, what it gets is either a primitive value or an object reference. This may be assigned to an (existing) local variable or parameter, assigned to an (existing) static or non-static member, assigned to an (existing) element of a previously allocated array, or simply used and discarded.
In no case does new storage need to be allocated to hold either a reference or a primitive value.
Typically, one word of memory is all that is needed to store an object or array reference, and a primitive value typically occupies one or two words, depending on the hardware architecture.
In no case does space need to be allocated by the caller to hold some object / array returned by a method. In Java, objects and arrays are always returned using pass-by-value semantics ... but that value that is is returned is an object or array reference.
For more information, please refer to these resources:
Class metadata: a user guide
What is the difference between PermGen and Metaspace?
Java 8: From PermGen to Metaspace
About G1 Garbage Collector, Permanent Generation and Metaspace