CODEWITHSUNDEEP
javac++
Björn Hallström
Björn Hallström

Reputation: 3833

How objects are stored in memory - Java (c++)

I have a memory question regarding creating objects in java-language.

When one creates an object in java a certain memory-space is occupied on the heap - correct? But what is part of this memory? Is it membervariables or both membervariables and methods? Could it be so that several object that refers to the same class share something?

Let say I have the following class

 class MyClass {

     //Membervariables
     protected int age;
     protected long dateOfBirth;


    /**
     * Constructor  
     * @param age
     */
    public MyClass(int age) {
        this.age = age;
    }


    /**
     * 
     * @param dateOfBirth
     */
    protected void setDob(long dateOfBirth) {
        this.dateOfBirth = dateOfBirth;
    }


    /**
     * 
     * @return
     */
    protected int getAge() {   
        return this.age;
    }


    /**
     * 
     * @return
     */
    protected long getDob() {
        return this.dateOfBirth;
    }
  }

So in this class I have the following: - Two membervariables - one int and one long

In the main-method I create two-instances (objects) of this class:

 MyClass myClass1 = new MyClass(10);
 MyClass myClass2 = new MyClass(11);

So my question is:

1) How could this be depicted in the computers memory?

2) Could the same "architecture" of how things are stored in memory concerning objects be applied to c++ as well?

Thanks in advance!!!

Upvotes: 3

Views: 4352

Answers (4)

Peter Lawrey
Peter Lawrey

Reputation: 533432

When one creates an object in java a certain memory-space is occupied on the heap - correct?

Probably, but the JVM can place it on the stack or optimise it away completely.

But what is part of this memory?

If you have a generational collector, small objects are placed in the Eden space and large objects are placed in tenured space.

Is it membervariables or both membervariables and methods?

Just variables. The object has a link to the class which holds all the loaded methods.

Could it be so that several object that refers to the same class share something?

Yes, of course. But this is not a requirement, just a more optimal solution.

1) How could this be depicted in the computers memory?

A 64-bit JVM has a 16-bytes header which include the hashCode and a reference to the class. This is followed by the fields. To improve memory access, the wider fields appear together to reduce the amount of padding needed.

2) Could the same "architecture" of how things are stored in memory concerning objects be applied to c++ as well?

For C++ object with virtual methods, they will have a link to the vtable also.

Upvotes: 2

davmac
davmac

Reputation: 20631

The Java language spec doesn't specify heap layout. In practice, most Java objects are going to have at least a "vtable pointer" (terminology questionable) which points to a table of method vectors (possibly method pointers, but also quite possibly a series of 'jump' instructions) and other run-time type information, and then data members. So with your example, the heap layout of the object might look like:

(4 bytes) vtable pointer (points to MyClass vtable)
(4 bytes) age
(8 bytes) date of birth

For any two objects of the same class, the vtable pointer should have the same value. So, the table of method vectors, and the methods themselves, are each present only once in the address space.

Please bear in mind that is just a (simplified) example and implementations of Java need not adhere to this.

Regarding the second part of your question, C++ uses the same techniques; but again, heap layout isn't specified completely in the language spec. Of course objects in C++ need not necessarily be stored on the heap (and the same is true in Java when certain optimizations come into play), but the memory layout of an object is generally not dependent on where it is allocated.

Upvotes: 1

Hot Licks
Hot Licks

Reputation: 47699

An object consists of a pointer to the internal version of the class, an area used for synchronized locking, an area of GC flags, and the instance fields defined in the class. (Note that an object reference field is only a pointer -- the referenced object is allocated separately.)

Methods are located by following the class pointer to the class and indexing a method table in the internal class object.

Your object above, in a 64-bit JVM, would be roughly:

  • Class pointer - 8 bytes
  • Lock variable - 8 bytes
  • GC flags - 4 bytes
  • Hash value - 4 bytes
  • dateOfBirth - 8 bytes
  • age - 4 bytes

36 bytes total. (Less, of course, in a 32-bit JVM.) The 36 bytes would likely be rounded up to 48 bytes to put it on a 16-byte boundary, or at least 40 to put it on an 8-byte boundary.

(This is one possible implementation. There are tricks that can be used to reduce/combine the space for the lock and GC fields, eg. But the basic principles apply.)

Upvotes: 3

Paul Evans
Paul Evans

Reputation: 27567

Object data goes on the heap, Class data and member functions are shared

Upvotes: 1

Related Questions