How would the memory look like for this object?

Question

I am wondering how the memory layout for this class (its object) would look like:

class MyClass
{
    string myString;

    int myInt;

    public MyClass(string str, int i)
    {
        myString = str;
        myInt = i;
    }
}

MyClass obj = new MyClass("hello", 42);

Could anyone visualize that?

Update:

Based on the answer from Olivier Rogier and the comments from ckuri and Jon Skeet I tried to come up with a high level chart, heavily influenced by the devblog article mentioned by ckuri.

So to my understanding:

1. obj (8 bytes reference) points to the object including metadata (actually not to its beginning, but let's ignore that for simplicity).

2. At this place the myInt is stored and the myString reference value (which is the reference to the real string value)

I don't want to got into the last details, but what I am still curious about:

1. If obj.myString shall be accessed, are there two "lookups" necessary, e.g. first looking up obj, then following it and looking up myString or is there something like a global address table where the address for obj.myString is directly stored?

2. Where is the reference value of obj stored? Is it part of the program object block like myString is part of the obj object block? (assuming obj is created inside an instance program)

Answer 1

At this place the myInt is stored and the myString reference value (which is the reference to the real string value)

Let's make sure you're not going down bad paths here.

First off, it's unclear to me why you re-ordered the integer and the string in the diagram compared to the source code. It is implementation-defined how the string and the integer are packed, and in what order, and whether there are any padding bytes. If you care about these details, ask a more clear question.

Second, it is unclear what you mean by "the real string value". Strings are of reference type. The real value of the string is the reference. The values of the contents of the string are in the referenced location.

if obj.myString shall be accessed, are there two "lookups" necessary, e.g. first looking up obj, then following it and looking up myString

I assume that by "lookup" you mean dereference.

So for example, if we have:

var obj = whatever;
char c = obj.myString[1];

then yes, we have two dereferences. The . dereferences obj to get myString, which is a reference. The [1] dereferences myString to get the char.

Where is the reference value of obj stored?

obj is a variable. A variable is a storage location. That storage location can be in a number of places:

• If obj is short lived, or even better, ephemeral, then it can be enregistered or put on the short term pool. (More commonly known as the stack, but it is a better habit in my opinion to think of the short term pool in terms of its semantics, namely, storage that lives not longer than activation. The stack is an implementation detail.)

• If obj is not known to be short lived then it goes on the long-term pool, also known as the managed heap.

Answer 2

Each instance of a class or struct has a "personal memory space" for data, but methods are shared once for all objects.

First, you need 4 bytes on x32 or 8 bytes on x64 to store the reference to the memory address of the object (reference is a hidden pointer to forget to manage it).

Next, the object has two data members here:

• One integer that takes 4 bytes.
• One string that here takes 5 chars : 5x2 bytes = 10 bytes.

So for data the object takes 18 bytes on x32 or 22 bytes on x64 system.

Since string object contains an integer for the length, the size is a little more than that : 22 on x32 and 26 on x64.

Since string is a reference, we need to add again 4 or 8 bytes => 26 or 34 bytes.

Since string has some other static and instance fields in the class declaration like the first char, it takes a little more than this.

Is string actually an array of chars or does it just have an indexer?

In addition to that, the memory in the code segment has the instructions of the code of methods. This code is common for all instances.

In addition to that, there are class tables and virtual tables to describe types, methods signatures and polymorphism rules.

If the object is instantiated in a method it uses the heap memory.

If the object is instantiated in the declaration as a class member, I don't know how works .NET but it may be allocated in the data segment of the processus.

And memory is like a train where wagoons are the bytes.

Here is a pseudo-diagram of the memory.

It is not the very true reality but it may help to understand:

Does accessing a variable in C# class reads the entire class from memory?

C# Heap(ing) Vs Stack(ing) In .NET

A byte is the elementary unit of the memory that stores one value at a time between 0 and 255 (unsigned) or -128 and +127 (signed).

Learn the basics about C# data types' variables

Shifting Behavior for Signed Integers

A Tutorial on Data Representation

---

Seeing this sketch today (2021.01.28) I realize it may be mlisleading, and it is why I wrote "It is not the very true reality but it may help to understand", because in reality the code of the implementation of methods are loaded from the binary files EXE and DLLs when the process is starded and is stored is the CODE SEGMENT, as all data, static (literals) and dynamic (instances) are in the DATA SEGMENT (if things had not changed since x32 and protected mode). Methods' non-virtual tables as well as methods' virtual tables are not stored in the data segment for each instance of objects. I don't remember details but these tables is for code. Also Data of each instance of an object is a projection from its definition as well as its ancestors, in one place, one full instance.

Memory segmentation

x86 memory segmentation