Where is the 'this' variable stored?

Question

Let's take this simple c++ program as an example:

#include <vector>
class A
{
  void fun() { a = this + 1; }
  A* a;
};

main()
{
  std::vector<A> vec;
  vec.resize(100);
}

Forgetting for the moment that this is a pointer to some instantiation of A, this question is about the variable this itself, and where its contents (the value of the memory address) is stored.

It can't be a literal because the compiler can't know the location of class A, so its contents must be allocated somewhere on the stack or heap as a variable. In this case the instances of A are allocated on the heap; does this mean the this pointer is also on the heap?

Looking at the resize call of vec, a compiler might do something like this under the hood:

std::vector<A>::resize(this, 100); // where 'this' is a pointer to vec

So my question is, where does the this pointer come from? Ie. where is the contents of this (the 32/64-bit memory address value) stored in memory for it to be passed to this method?

I would presume it can't be a normal member; so my first thought was that it's a mangled global variable of some sort, but then by storing an unknown number of them in a vector I don't see how the compiler could achieve this either. Where is the contentx of the this variable stored in relation to the contents of the A class member to which it refers?

If the standard has something to say about this, I would prefer an answer with reference to the standard.

Note that the reason I want to know is because I am concerned about false sharing of the memory allocated for the this object if I modify member variables. Knowledge of where the this object is stored might affect padding decisions.

Answer 1

The point is that this is an implicit formal parameter (containing the address of the object whose method you are calling). It is not a local variable.

Look at the generated code of your program. I compiled (on Linux/Debian/Sid/x86-64 with GCC 4.9.1) your example arman.cc with

  gcc -O1 -fverbose-asm -S arman.cc

and got the function main below

         .globl  main
         .type   main, @function
 main:
 .LFB512:
         .cfi_startproc
         .cfi_personality 0x3,__gxx_personality_v0
         .cfi_lsda 0x3,.LLSDA512
         pushq   %rbx    #
         .cfi_def_cfa_offset 16
         .cfi_offset 3, -16
         subq    $48, %rsp       #,
         .cfi_def_cfa_offset 64
         movq    $0, 16(%rsp)    #, MEM[(struct _Vector_impl *)&vec]._M_start
         movq    $0, 24(%rsp)    #, MEM[(struct _Vector_impl *)&vec]._M_finish
         movq    $0, 32(%rsp)    #, MEM[(struct _Vector_impl *)&vec]._M_end_of_storage
         movq    $0, (%rsp)      #, MEM[(struct A *)&__x]
         movq    %rsp, %rcx      #,
         movl    $100, %edx      #,
         movl    $0, %esi        #,
         leaq    16(%rsp), %rdi  #, tmp92
 .LEHB0:
         call    _ZNSt6vectorI1ASaIS0_EE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPS0_S2_EEmRKS0_  #
 .LEHE0:
         movq    16(%rsp), %rdi  # MEM[(struct _Vector_base *)&vec]._M_impl._M_start, D.10014
         testq   %rdi, %rdi      # D.10014
         je      .L34    #,
         call    _ZdlPv  #
         jmp     .L34    #
 .L33:
         movq    %rax, %rbx      #, tmp91
         movq    16(%rsp), %rdi  # MEM[(struct _Vector_base *)&vec]._M_impl._M_start, D.10014
         testq   %rdi, %rdi      # D.10014
         je      .L32    #,
         call    _ZdlPv  #
 .L32:
         movq    %rbx, %rdi      # tmp91,
 .LEHB1:
         call    _Unwind_Resume  #
 .LEHE1:
 .L34:
         movl    $0, %eax        #,
         addq    $48, %rsp       #,
         .cfi_def_cfa_offset 16
         popq    %rbx    #
         .cfi_def_cfa_offset 8
         ret
         .cfi_endproc

You see that some space for your vec is allocated on the stack (e.g. with subq $48, %rsp etc...) and then the address of that zone on the stack is passed as the this formal argument (using the usual x86-64 ABI conventions, which dictates (p 20) that the first argument of function is passed thru register %rdi) so you could say that this is, at the beginning of some member function, in the register %rdi ...

IIRC, the wording of the C++ standard are vague enough to permit the this argument to be passed in a special way, but all the ABIs I heard of are passing it exactly as the first (pointer) argument of usual C functions.

BTW, you should trust the compiler and let it pass this as convenient and as prescribed by ABI specifications.

Answer 2

The pointer this is not stored anywhere in relation to the class instance (because if you already have the class instance, getting its pointer is trivial!). Rather it behaves like a hidden argument that is always implicitly passed into member functions such as resize. (In some languages like Python this is passed explicitly.)

Note that the standard says nothing about where this is stored. You aren't allowed to take the address of this because it's not a variable. Hence your question concerns entirely an implementation detail.

As a concrete example,

class A
{
public:
  void fun(int x) { a = this + x; }
  A* a;
};

void foo(A& a)
{
  a.fun(1);
}

This is semantically equivalent to the following:

struct A
{
  A* a;
};
void A_fun(A* _this, int x) { _this->a = _this + x; }

void foo(A& a)
{
  A_fun(&a, 1);
}

So it is possible for a compiler to implement member functions in this way (or something similar). How an actual compiler implements it will vary, however.

Answer 3

Truth be told that there are various ways that a compiler can implement this, and it shouldn't matter to you which one is actually used. Yes, there may be some subtle interactions with the processor that would impact performance but the compiler writers almost certainly know about it way better than you do.

But the simplest approach is to simply treat this like it was any other parameter. So for a class like:

class Foo
{
    void bar();
    ...
};

Foo foo;
foo.bar();

The code that is produced is probably pretty much the same as the C equivalent of:

struct Foo
{
    ...
}

Foo_bar(Foo * foo) {
}

Foo foo;
Foo_bar(&foo);

So inside Foo::bar, this simply comes from being a hidden parameter to the method. In that respect, it works just like any other parameter.

However, you might want to know, where does the pointer come from in the first place? At some point in time the Foo object was created. It may have been created as a local variable, or perhaps via new. In either case, the program starts the creation of Foo by selecting the piece of memory to create the object in. It knows the correct address of Foo, because it selected or was given the piece of memory to put Foo into. It simply keeps track of that address for when it needs that pointer later.

Answer 4

Arman, looking over your questions, I'd like to emphasize one aspect I think you're missing. Your instinct that the this pointer has to be stored somewhere is absolutely right. But, your mistake is in limiting the choices to "heap" and "stack". These are certainly common places for data to be stored, but there are others (and there are other besides these!):

• CPU registers
• "the global section"
• thread-local storage

When arguments are passed to a function, usually the first "couple" arguments or so are placed in CPU registers. The details vary depending on many things: the processor architecture (x86 vs ARM vs ARM64 vs ...), the number of arguments, the types and sizes of the arguments (integers, pointers, floats, vector types), and on certain code annotations the function may have (which you're rarely going to have to deal with).

In almost every processor you're likely to program for, the 'this' pointer will be passed as the implicit 0th argument of a member function, which means it will be passed via a CPU register. In x86_64 that is register ECX, and in ARM that would be register r0.

Answer 5

It depends on the calling convention of the compiler but usually it's passed as the first (hidden) argument and not stored in A anywhere. The first argument is then either passed as i a register or on the stack.

Answer 6

Annotating your example:

main()
{
  std::vector<A> vec;
  vec.resize(100); // What really happens: vec.resize(&vec, 100);
}

The compiler emits code that calculates the address of the class instance vec and passes it as the first parameter to any method call against that instance. There is no global variable 'this'. There is no member variable 'this', there is just an address passed as a formal parameter to a method call. You can refer to it in your method body just like any other parameter.

Answer 7

It sounds like you want to know where the contents of an instance of the class are stored. The answer is, it depends.

Classes can be instantiated on the stack, on the heap, or indirectly on the heap as in your vector example.

In your vector example, following the vec.resize(100), there are 100 instances of class A constructed in the memory reserved by the vector vec. The memory for the vector vec is allocated on the heap. Hence, the instances of a are indirectly stored in the heap.

About this

this is quite simply the address of an instance of the class. There can be many instances of a class. In your example, there are 100 instances of class A, each with their own this. The this for an instance is not stored anywhere. It is just the address of the instance.

For example, call vec[3].fun(), and the a member of the instance of class A at the third location of vector vec will be a pointer to the instance of class A at the fourth location of vector vec. (Of course, you can in turn, call fun() using the member variable a.)

The value of this, within a method call is determined by the caller of the method. The pointer to the instance at the time of the method call becomes the this pointer to the method call.