How reference type works internally?

Question

public class ReferenceType
{
   public int FName { get; set; }        
   public int LName { get; set; }        
}  

ReferenceType rt1;          //Line 6
rt1 = new ReferenceType();   //Line 7 >>have just split a single line statement<<

As everybody knows

how reference type works, in above code scenario

rt1 allocates a portion of memory in stack, to hold reference of some object, in future (Line 6)
rt1 is assigned reference of an object that is created on heap [ a specific]

Now, what really is this reference looks like internally, does rt1 holds an address of the (created) object, an hexadecimal, just like a pointer does in c++, or something else ?

IMO this is pretty to broad and involves too many CLR implementation details. Something like a C++ pointer (I don't understand what you mean with _hexadecimal_). In reality you'd better call it _handle_ instead of pointer (because object _may_ be moved in memory by GC). — Adriano Repetti, Jan 01 '14 at 10:06
[What is the difference between a C# Reference and a Pointer?](http://stackoverflow.com/questions/430112/what-is-the-difference-between-a-c-sharp-reference-and-a-pointer) — Soner Gönül, Jan 01 '14 at 10:06
You may find this useful:http://www.codeproject.com/Articles/20481/NET-Type-Internals-From-a-Microsoft-CLR-Perspecti — NoChance, Jan 01 '14 at 10:06
This question has been asked (and answered) before: http://stackoverflow.com/questions/5920636/how-a-reference-in-c-sharp-is-implemented-internally?rq=1 — StevieB, Jan 01 '14 at 10:07
@adriano hexadecimal i mean the the address location in the memory, just like we get in c++... — x-code, Jan 01 '14 at 10:07
It's an implementation detail that you shouldn't concern yourself with. It *may* be a pointer, but it doesn't have to be. — Jon Skeet, Jan 01 '14 at 10:08
@jon was just curious wheather the reference of c# has anything to do with pointers.. just was making sure...like that what could be... — x-code, Jan 01 '14 at 10:09

score 4 · Answer 1 · answered Jan 01 '14 at 10:09

4

Your first dot point is incorrect.

A reference is added on the stack. This reference then references memory on the heap.

(Disclaimer: The below statement is how I believe it works.. it certainly is this way in the SSCLI)

References are implemented as pointers.. but there is no formal requirement stating that they must be pointers. This could change at any point at Microsofts discretion. They (currently) point to the method table of an object.

An object looks like this:

       +-------------+
       |             |
       |  Reference  |
       |             |
       +------+------+
              |
              |                +-------------------------------+
              |                |          Object header        |
              +--------------->|-------------------------------|
                               |                               |
                               |                               |
                               |                               |
                               |           Method table        |
                               |                               |
                               |                               |
                               |                               |
                               |                               |
                               +-------------------------------+

The header contains a sync block index and a pointer to the object type definition. It is important to know though, that references know what they point to.. a pointer doesn't have to know that. This is enforced by the CLR.

Yes, this is an implementation detail that you don't have to be concerned about.. but I don't think there is any problem knowing about it.

As long as you don't rely on implementation details.. knowing about them won't kill you.

answered Jan 01 '14 at 10:09

Simon Whitehead

63,300
9
114
138

1

+1... yeah just remembered that(stack) point.... – x-code Jan 01 '14 at 10:11
Method table? I can't swear (and it may be changed) but it shouldn't point to that. It should (had?) to point to a _handles_ table (there, deferencing another pointer, you'll have method table). Like you said it's not even how C++ pointers are implemented (well at least in compilers I know) – Adriano Repetti Jan 01 '14 at 10:18
@Adriano It certainly does point to the method table in the SSCLI (without access to Microsofts CLR we can't be sure about their implementation). However, the extra hop you may be thinking of is for method _thunks_ before JIT compilation .. ? – Simon Whitehead Jan 01 '14 at 10:21
@downvoter I would be happy to amend this if you believe something is incorrect. Like I stated.. this is based soley off the Shared Source CLI.. so I don't presume to know the inner workings of Microsoft's CLR. – Simon Whitehead Jan 01 '14 at 10:24
I just suppose but: fixed pointer to a reference will access its fields then it'll point to something else than method table. If dumped it's not same value as reference itself. Finally a "call" doesn't need deferencing method table (when JITed) but "callvirt" does. Double deferencing (object itself and virtual method) is one of reasons it's slower. Then object reference shouldn't point directly to methods but to fields (and they don't have to grow up together). Again I just suppose... – Adriano Repetti Jan 01 '14 at 10:32
I'm not sure what you mean by "fixed pointer to a reference will access its fields then it'll point to something else than method table". If you point to a field, internally it is just a `(this + 4) + fieldOffset` to jump over the method table to a specific instance field (or +8 on 64-bit systems)... and its just the value of that address being pushed into a new pointer. `call` doesn't dereference.. because the reference already points to the method table. Again, its a simple offset jump to the required method to call (or the thunk if it hasn't been JITted yet). – Simon Whitehead Jan 01 '14 at 10:47
It's really hard to have a discussion about this in the format that SO provides :/ I think we're basically talking about the same thing .. ? – Simon Whitehead Jan 01 '14 at 10:48
Yes, it's what I mean! If `this+4` points to fields (and `this` points to pointer to method table) then `this` doesn't point to method table but to a structure. Moreover (because objects _may_ be moved in memory when GC compacts free space) then reference itself _may_ be an entry in a table (like a handle) instead of a raw pointer. – Adriano Repetti Jan 01 '14 at 10:51
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/44270/discussion-between-simon-whitehead-and-adriano) – Simon Whitehead Jan 01 '14 at 10:52

How reference type works internally?

1 Answers1