views:

5168

answers:

4

Please enlighten me.

public class SomeObject{

    private String strSomeProperty;

    public SomeObject(String strSomeProperty){
     this.strSomeProperty = strSomeProperty;
    }
    public void setSomeProperty(String strSomeProperty){
     this.strSomeProperty = strSomeProperty;
    }
    public String getSomeProperty(){
     return this.strSomeProperty;
    }
}

What happens in the memory when a class instantiates the above object?

In Class SomeClass1:

SomeObject so1 = new SomeObject("some property value");

In Class SomeClass2:

SomeObject so2 = new SomeObject("another property value");

How memory is allocated to the newly instantiated Object and its properties?

A: 

Googled for "Java Memory Management" and got this - http://www.javaworld.com/javaworld/javaqa/1999-08/04-qa-leaks.html

Vijay Dev
+2  A: 

Let's step through it:

SomeObject so1 = new SomeObject("some property value");

... is actually more complicated than it looks, because you're creating a new String. It might be easier to think of as:

String tmp = new String("some property value");
SomeObject so1 = new SomeObject(tmp);
// Not that you would normally write it in this way.

(To be absolutely accurate - these are not really equivalent. In the original the 'new String' is created at compile time and is part of the .class image. You can think of this as a performance hack.)

So, first the JVM allocates space for the String. You typically don't know or care about the internals of the String implementation, so just take it on trust that a chunk of memory is being used to represent "some property value". Also, you have some memory temporarily allocated containing a reference to the String. In the second form, it's explicitly called tmp; in your original form Java handles it without naming it.

Next the JVM allocates space for a new SomeObject. That's a bit of space for Java's internal bookkeeping, and space for each of the object's fields. In this case, there's just one field, strSomeProperty.

Bear in mind that strSomeProperty is just a reference to a String. For now, it'll be initialised to null.

Next, the constructor is executed.

this.strSomeProperty = strSomeProperty;

All this does is copy the reference to the String, into your strSomeProperty field.

Finally, space is allocated for the object reference so1. This is set with a reference to the SomeObject.

so2 works in exactly the same way.

slim
No, it's not more complicated than it looks. "a" and new String("a") are not equivalent expressions. String literals are interned by the compiler. They don't incur additional heap allocations when they are used.
bendin
http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5
bendin
Touche :)However I think interning is conceptually even more complicated than what I decribed. I guess the appropriate answer depends on the intent of the question.
slim
Interning may conceptually more complicated, but it has the advantage of being correct.
Tom Hawtin - tackline
I'll draw the analogy with chemistry. In British schools, 16 year olds are taught Bohr's model of the atom. It is useful in many cases, and it is simpler than the truth, which is taught at higher levels. I will edit the text to clarify though.
slim
+1  A: 
  • Read about the JVM Stack and Heap.
  • Read about references, how Java passes by reference and what this really means.
  • Read about what happens when you use a String literal in Java, and how Strings are handled slightly differently to other objects in the heap (In a String-specifc section of the Heap).
  • Read about what happens when you use the new keyword.

    Once you understand these things, you'll be able to answer your own question.
James Camfield
+1  A: 

Determining Memory Usage in Java by Dr. Heinz M. Kabutz gives a precise answer, plus a program to calculate the memory usage. The relevant part:

  1. The class takes up at least 8 bytes. So, if you say new Object(); you will allocate 8 bytes on the heap.
  2. Each data member takes up 4 bytes, except for long and double which take up 8 bytes. Even if the data member is a byte, it will still take up 4 bytes! In addition, the amount of memory used is increased in 8 byte blocks. So, if you have a class that contains one byte it will take up 8 bytes for the class and 8 bytes for the data, totalling 16 bytes (groan!).
  3. Arrays are a bit more clever, at least smaller primitives get packed. I'll deal with these later.

As people have pointed out in the comments, Strings are a special case, because they can be interned. You can reason about the space they take up in the same way, but keep in mind that what looks like multiple copies of the same String may actually point to the same reference.

Craig P. Motlin
Note that this is 7 years old, and based on empirical evidence using a particular JVM on a particular operating system at that time (the article says as much). Unless you know for sure what JVM you're going to be running on, you can't be this precise.
slim
Good point. I wouldn't be surprised if some things that used to take 4 bytes take 8 on a 64 bit platform. However, the program determines the size of an object empirically. Running it on the target VM will give a precise answer.
Craig P. Motlin
That's cool. Thanks.
ZiG
It's also possible that newer VMs have a more efficient approach to storing booleans, shorts etc., or that the behaviour varies between platforms (JME could be optimised for memory), or that the JVM changes strategy as it approaches heap limits.
slim