Where does the Java JVM store primitive variables, and how is the memory used by primitives freed after use?
I guess it is on the stack?
Simplistic answer: it depends on where the variable is declared, not on its type.
Local variables are stored on the stack. Instance and static variables are stored on the heap.
Don't forget that for reference type variables, the value of a variable is a reference, not the object. (Arrays are reference types too - so if you have an int[], the values will be on the heap.)
Now, this is potentially an overly simplistic answer, because a smart VM may be able to detect if a particular reference type variable refers to an object which can never "escape" the current method. If that's the case, it could potentially inline the whole object on the stack.
But conceptually this model is accurate. So a variable of type int which is declared as an instance variable like this:
class Foo
{
private int value;
...
}
will conceptually live on the heap, as part of the data of any instance of Foo. It will be freed as part of freeing the instance - it's just 4 bytes within the block of data representing a Foo instance; it doesn't need separate deallocation.
Where a variable is stored depends on whether a variable is a local variable or an instance variable.
Local variables are stored on the stack. Instance and static variables are stored on the heap.
Let me explain this with an example. Lets say we have an instance variable animal of some custom class Animal.
Animal animal = new Dog();
Here animal is just a reference and is located on the stack. The actual object is allocated memory on the heap. This reference animal will point to this object memory allocated on the heap. So if you have 3 reference pointing to the same object.
Animal animal1 = new Dog();
Animal animal2 = new Dog();
Animal animal3 = new Dog();
All three reference will be in stack. When I say reference it is just a pointer pointing to the object on the heap. In terms of memory this reference holds the address(not actually there a bit more abstraction here) of the object on the heap. So 4 bytes on 32 bits and 8 bytes on 64 bits. Only when all the three references are dereferenced i.e they are no longer in scope(or rather no longer pointing to the original object) then only garbage collector is free to deallocate the memory allocated to the object on the heap.
There is a slight variation when we store primitive types or String literals.Unless you explicitly create their object using new() operator they are created and stored in permGen area of Heap.
So both references firstString and secondString in
String firstString = "Stack";
String secondString = "Stack";
will point to the same object in the String pool. It would point to different objects when we create them using new().
Class objects, including method code and static fields: heap.
Objects, including instance fields: heap.
Local variables and calls to methods: stack..
Related
Since JVM allocates memory to static variable type in Method Area. But when it comes to static String type does it refer to heap area from method area or it provides memory in Method Area there itself. If it refer to heap area then String will have the same behaviour(for below example)?
Example:
static String s1 = new String("Aman");
static String s2 = "Aman";
You are conflating the variables s1 and s2 with the objects they refer to.
The objects are in the heap. The literal "Aman" is in the string pool subdivision of the heap.
The variables, being static, are in the class.
Since JVM allocates memory to static variable type in Method Area.
Yes you are right, as static variables are class level variable since they are part of the reflection data (class related data, not instance related) they are stored in the PermGenSpace > Method Area section of the heap,
But when it comes to static String type does it refer to heap area
from method area or it provides memory in Method Area there itself.
See objects always get memory to heap area only no matter what, but yes static reference variables will be stored in Method Area.
Coming to your code,
static String s1 = new String("Aman");
Above line of code will create two objects 1st object through new keyword and 2nd objects through string literal "Aman" in the heap memory but remember the string literal will be stored in StringConstantPool and refer 2nd object in the heap from StringConstantPool and after that you are assigning the reference of objects which is in the heap to reference variable which is exists in MethodArea.
static String s2 = "Aman";
Now when compiler executes above line it will check "Aman" is already in the StringConstantPool it will not create another object instead it will return the same object which is already in the heap memory to static reference s2 which is in the Method Area.
I hope it will help.
I've been practicing component based design pattern and I was wondering if when you initialize an variable without reference meaning initialized as null, Java go ahead and attribute a space in memory that has the size of the variable even though it is set to null so that eventually when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
A variable whose type is a reference type occupies the same amount of space whether it contains null or a reference to an object.
However, the variable only holds the reference ... not the object itself.
... when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
Erm ... no. When you later "initialize" the variable, you are assigning a reference to the variable. You are not copying the fields of the object.
For example:
SomeType s = null; // the declaration sets aside space for one
// reference, and the initialization assigns
// `null` to it.
s = new SomeType(...) // the 'new' expression creates the object and
// which allocates the space, etcetera
// the assignment merely assigns the reference
// for that object to 's'.
What if "s" is an array of "Sometype" instead still initialized to null, will it be legit to assume that only space for one reference will be saved until you create a new valid reference for an array of the relevant type?
An array type is also a reference type. So, yes, the answer is the same. A declaration SomeType[] s would reserve space for one reference.
I was wondering if when you initialize an variable without reference meaning initialized as null, Java go ahead and attribute a space in memory that has the size of the variable even though it is set to null
Yes memory is allocated for the variable, but this is only a tiny address space bit of memory and nothing else. No memory is allocated for the eventual object.
so that eventually when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
When you create an instance of anything, then memory is allocated on the heap for the object, and this happens whether or not the object is assigned to a variable, to no variables, or to 50 variables, and any variable that refers to the object has its address space pointing at the object's location on the heap (perhaps -- I don't think that the actual mechanics, the hows, are fully specified)
Have a look at oracle documentation page regarding objectcreation
Point originOne;
If you declare originOne like this, its value will be undetermined until an object is actually created and assigned to it. Simply declaring a reference variable does not create an object.
For that, you need to use the new operator, as described in the next section. You must assign an object to originOne before you use it in your code.
Instantiating a Class
The new operator instantiates a class by allocating memory for a new object and returning a reference to that memory. The new operator also invokes the object constructor.
Note: The phrase "instantiating a class" means the same thing as "creating an object." When you create an object, you are creating an "instance" of a class, therefore "instantiating" a class.
The new operator returns a reference to the object it created. This reference is usually assigned to a variable of the appropriate type, like:
Point originOne = new Point(23, 94);
I hope above picture clarifies your queries.
The size of reference will be 4 bytes or 8 bytes. Have a look at this SE question:
How big is an object reference in Java and precisely what information does it contain?
In Java, when we only declare a variable of a class type, only a reference is created (memory is not allocated for the object). Is to hold the reference t somewhere space will be created on heap ? or if i'm wrong then what happens exactly in memory when we just declare variable ?
Test t;
In Java, when we only declare a variable of a class type, only a reference is created (memory is not allocated for the object).
This is correct.
Is to hold the reference t somewhere space will be created on heap?
The answer depends on the context in which the declaration appears. If the said declaration is part of an object (i.e. t is a field) then the space for the reference would be allocated from the heap, along with the space for the rest of the object containing the field. Otherwise, the space for the reference would be allocated in JVM's stack frame.
When you declare a variable:
Test t;
space is made for the reference (a fixed amount, doesn't depend on the number of members in the class). When you instantiate a variable, using the new keyword:
t = new Test();
then space for the variable is made on the heap, and t references that space. This has to be large enough to hold all the members of a Test.
I know that when declaring object instances in c++ like so:
Object object
the Object constructor is called and memory is provided for that object, however i find that when you do this in java the object instance doesn't have a value until:
object = new Object()
is written. I want to know specifically when memory is provided for the object. I thought that both construction and the new keyword allocated memory so Object object = new Object() seems redundant. I read on oracle's site that declaration "reserves" memory and new "allocates" memory, I would like to know what is the difference between the two.
You need to differentiate between the space required for the variable and the space required for the object. Bear in mind that the value of the variable is just a reference - very much like a pointer in C++. So if you have:
Object x = null;
then the variable x itself takes up enough space for a reference (usually 4 or 8 bytes). Now if you have:
x = new Object();
that creates an object - the value of x is now a reference to the newly created object. x itself takes up the same amount of space as before, but there's also the space required for the object itself (basically the fields, a reference for the type of the object, and data for synchronization and house-keeping).
When you do something like
Object object = new Object()
in Java, object is a reference to the actual instance on the managed heap. Compared to C++, that's roughly doing
Object* object=new Object()
So when you do
Object object;
in Java, a place is created for the 'reference' to a instance.
Similar to
Object* object;
in C++.
Object foo=null;
in meaning of C++ creates reference foo to the object of class Object. So, it consumes memory for reference only.
Object realFoo=new Object();
creates such reference and also real object with whatever is with this object. So, it is memory for the reference and object itself.
In Java there is no memory reservation - only memory allocation.
declaration reserves memory: parameters and variables inside a method will have memory reserved for them in the stackframe.
allocates memory: at runtime, when executing "new", memory will be allocated for the new Object on the heap
It's important to understand that in Java, Object object is simply a reference to an Object called object. If you're familiar with C++, you can think of this reference as a pointer (though it's not quite the same).
On a 64-bit machine, the object reference is 8 bytes. When you actually instantiate an Object using the new keyword and assign it to the reference, this is where memory is allocated for your Object.
While reading on Thread Safety I came across this issue.
If I'm correct method local Primitives and object references lives inside a stack and actual objects pointed by the references inside the stack lives in the heap.
But when it comes to method local non primitive object initialization, wouldn't that cause a concurrency issue ? I mean if the method locals non primitives lives in the heap and only the pointers lives in the stacks, isn't it the same as of instance variables ?
Can someone please help me to understand this....
PS
Think of two threads with each having two stacks of their own and one heap. What I understood is that the two threads keep their method local primitive variables inside their stacks. I have no issue with that.
But what if we have a method with non primitive method local variables ? Then if the object for that variable is stored inside the heap, both the threads will have the access to the same object, won't they ? So if that's the case there would be Sync problems.
That is what I'm asking.
Thanks
But what if we have a method with non primitive method local variables
? Then if the object for that variable is stored inside the heap, both
the threads will have the access to the same object, won't they ? So
if that's the case there would be Sync problems.
I wonder why you will think the two references will refer to the same object.
The creation of the object referred is explicitly done by new (or other similar method, but idea is the same)
Therefore, unlike in C++, if you are declaring this in Java
Foo foo;
there is no Foo object instantiated. foo is just a pointer pointing to nothing.
This will create you a Foo object instance in heap.
Foo foo = new Foo();
If two thread is running this piece of code, thread 1 will have a Foo reference in stack, and ask to allocate a new Foo object in heap, and then assign the address of that Foo obj to the reference foo. Thread 2 is doing the same. Note that Thread 2 is also asking to allocate a new Foo object, it will be a different object from what Thread 1 is allocated.
That's the basic (and much simplified) idea.
Both threads could have access to the same object if they both have a reference to the object. If you have a method like the following:
public String concat(String a, String b) {
StringBuilder builder = new StringBuilder();
builder.append(a);
builder.append(b);
return builder.toString();
}
The StringBuilder object is indeed in the heap, but only one thread has a reference to this object. No other thread can have a reference to this StringBuilder. So it's inherently thread-safe.
If, on the contrary, you have the following:
public String concat(String a, String b) {
final StringBuilder builder = new StringBuilder();
new Thread(new Runnable() {
#Override
public void run() {
builder.append("haha!");
}
}).start();
builder.append(a);
builder.append(b);
return builder.toString();
}
Then you have a thread-safety issue, because you shere the locally created object reference with another thread, and StringBuilder is not thread-safe.
But what if we have a method with non primitive method local variables ? Then if the object for that variable is stored inside the heap, both the threads will have the access to the same object, won't they ? So if that's the case there would be Sync problems
You partially answered your own question.That reference value is stored in the stack but the actual object content is stored in heap and when you call new Object() each thread creates different new object that will be stored in the heap and each thread access the object it has created using the reference value stored in its own stack
Local variables are either primitives, references to objects created somewhere else (if you do an assignation), or references to newly created objects (using "new" operator)
For the first case, as you said, there is no issue.
For the last case, as you are locally craeting a new object, a new object will be created at every call, so no concurrency issue because there will be one object in the heap for each call
But for the second case, as the object has been created somewhere else, you have to think about concurrency
Just to toss in my thoughts regarding what may be your point of confusion: the heap is not managed like the stack. It is shared, yes - in that objects created by all threads are in the heap. However as each object is created, it's given a unique location/space in the heap. Two methods on two threads running concurrently and creating an object instance will create distinctly different objects in the shared heap.
They're created in this shared heap so that if method foo returns the object reference, or stores it, or calls another method that indirectly stores it... it won't be destroyed when foo returns and the stack is popped.
The magic of having a garbage collector is that you don't have to keep track of this "stuff" and destroy it yourself at some appropriate point in the future. Keeps your code simple, lets you focus on algorithms (or learning to program). But I digress...