I have a following class
class Student{
int rollNumber;
int marks;
public void setResult(int rollNumber, int marks){
this.rollNumber=rollNumber;
this.marks=marks;
}
public void displayResult(){
System.out.println("Roll Number= "+this.rollNumber+" Marks= "+this.marks);
}
}
Now I create two objects of type Student as follows
Student s1=new Student();
Student s2=new Student();
Now two different sets of memory is allocated for instance fields. Now my question is whether memory is allocated for methods (setResult and displayResult) twice or once?
Please see the following figure and can you help me saying which figure gives correct information.
2
The code for methods is part of the Class (more concisely, Class<Student>) and it is loaded into memory when the class is first loaded.
That said, when you execute any method additional memory is used, to allocate memory to parameters, local variables, temporary expression results, return values and so on. But such memory is allocated in the stack (the memory used when creating a new instance is allocated in the heap.
As per your question, it should be clear now that figure B is correct (although it does not reflect what happens when you actually call the method).
4
Instance fields (including property backing fields) get N-copies for N-objects.
Static fields get a single copy per class.
Methods are blocks of bytecode (or after JIT, blocks of native instructions) that are part of the program “image” or executable code segment. Methods are already part of the program image as it sits on disk. Once the image is loaded by the OS (or CLR), there is a single shared copy of the method code.
They aren’t part of “heap” or runtime allocation in general, except in cases where you may use the hostable compiler to compile new methods on the fly. Methods don’t get “allocated” like objects and they aren’t “allocated” relative to the object creation. They merely exist as part of the program before a single object is ever instantiated. Even lambdas / delegates aren’t allocated on the fly. The compiler creates classes on-demand to implement these other seemingly dynamic code objects, and they also exist as part of the bytecode image on disk.
UPDATES per comments:
The JVM standard has this to say:
2.5.4. Method Area
The Java Virtual Machine has a method area that is shared among all
Java Virtual Machine threads. The method area is analogous to the
storage area for compiled code of a conventional language or analogous
to the “text” segment in an operating system process. It stores
per-class structures such as the run-time constant pool, field and
method data, and the code for methods and constructors, including the
special methods (§2.9) used in class and instance initialization and
interface initialization.The method area is created on virtual machine start-up. Although the
method area is logically part of the heap, simple implementations may
choose not to either garbage collect or compact it. This version of
the Java Virtual Machine specification does not mandate the location
of the method area or the policies used to manage compiled code. The
method area may be of a fixed size or may be expanded as required by
the computation and may be contracted if a larger method area becomes
unnecessary. The memory for the method area does not need to be
contiguous.
So it is clear that (1) yes the spec does not dictate how this is done, but (2) it is analogous to the storage area for compiled code of a conventional language, ie. the text segment. This is the point I’m making.
8
object allocated in heap memory.when object are allocated the slot for all the instance variable is created and destroyed when the object are destroyed.so instance variable is also allocated in heap memory.And the local variable are created in stack at the time when the method are called.
1