How are objects stored in memory?

Question

I'm trying to understand how objects are stored in memory using the .NET Framework.

Given the following person class:

public class Person
{
    public string name { get; set; }

    public int age { get; set; }
}

I believe an initiated variable of type Person would have the following structure in memory:

Questions:

• Firstly, are their any major / obvious flaws in my understanding? (I'm almost certain there is, as it just seems way to in-efficient to handle objects in the way I am describing; especially in the way the name pointer points to the char collection for the string member)

• Secondly, for value type members of a class (I.E Age), are they stored within the object itself (so within the same memory address as the object), or do they get allocated their own address, and the object then points to it? (Such as my diagram shows)

• Similar to the above question, but for reference type members, does the object hold a pointer to the pointer? (I.E The name pointer referencing the char collection in my diagram)

• Finally, Would it make a difference if the members of my Person class were fields rather than properties?

Update: Updated diagram based on answers from Sweeper & Tim, which I believe is now correct.

Note: Pointer changed to reference as this is managed code.

Answer 1

In the .net world, pointers point to unmanaged memory, and object references refer to managed objects. Objects may be moved by the garbage collector at any time, so pointers to them would be destroyed without warning. The concept is the same, but there is a difference, since you can indeed have pointers in unsafe C# code. If you grab a pointer to an object, and that object moves, your pointer points to arbitrary memory space. An object reference, however, is preserved.

To the question of age. It is stored in the object itself, taking up 32-bits right in the structure-- not a reference/pointer to the int32

For reference type members it holds a reference, which is conceptually the same idea as a pointer and takes up 64 bits of space (or 32, depending on architecture), but somewhat different as I mentioned out above.

Finally, anonymous properties are really creating hidden fields and the auto-writing code that sets and retunrs those fields. Storage is the same, but there is a very minimal cost to accessing it through the property rather than the field directly.

Answer 2

There are some mistakes. You got the int member wrong, it is a value type. So no pointer, it is included in the storage for the Person object and takes 4 bytes. The name object reference doesn't look quite right either, it points to a String object. The chars in the string are included in the storage for the string, much like the int was. Or to put it another way, the size of the String object storage is variable, as big as necessary to store the chars.

So visiting the members of the Person object takes dereferencing just two pointers, a lot more efficient that way.

And yes, the variable of type Person stores just the pointer. The GC updates it when it compacts the heap.

Properties do not exist at runtime, it is an abstraction provided by the compiler. Most typically the compiler will allocate a field for it, unless you provide the getter and setter methods yourself. So "name" and "age" in your drawing are in fact fields, they'll have a different name.