When I create an object, is fresh memory allocated to both instance fields and methods or only to instance fields

Question

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.

Answer 1

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).

Answer 2

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.

Answer 3

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.