Memory location of .cs files

frank gruber

12y1.9k.NET

Instantiation generates 'activity' in the stack as well as heap. But do the actual class definitions (before) instantiation, technically reside in the stack or heap, or just part of a separate location in RAM?

thanks Gents,
Spatio

5 Replies

Know the answer? Post it — somebody with the same question will find it here.

naveen awasthi12y ago
i think it's use marshling to communicate between managed and unmanaged code
Anupam Singh12y ago
Thank you Vulpes.
Vulpes12y ago
Thanks, Anupam, but I don't have the time nowadays to even consider writing a book on .NET.

There are in any case some really good ones already including Jeffrey Richter's books which are where I learnt most of what I know about the internals of .NET in the first place.

Yes, the process I've just described only applies to managed types and objects.

Since the CLR is written in C++ it can access unmanaged code natively though, to assist with this, it does have built-in mechanisms to convert .NET types to and from unmanaged types where they're not already compatible with each other.
Anupam Singh12y ago
Hi Vulpes,

Nicely described !. You should write book on .net :), why don't you try so?
I never put any comment after your reply, because its always perfect.

I have a query here .How .NET framework process unmanaged code ? It should be quite different then this process .
Vulpes12y ago
Class definitions are stored in metadata tables in the .NET assembly itself.

However, when the application runs, the CLR creates an internal structure for each type (known as a 'type object') which contains a table of its methods and memory slots for any static fields it may have.

As the CIL for each method is compiled to native code, a block of memory is allocated to store this native code and a pointer to it is stored in its type object's method table. Each time the method is called execution jumps via the method table to the native code block.

These type objects and the native code blocks are allocated on the heap and persist throughout the lifetime of the application.

Each time an object of a class is allocated on the heap, a pointer to its type object is included in the object's memory. If a method of that object is called or a static field is accessed, the CLR then uses this pointer to take the appropriate action. Instance fields are, of course, stored within the object's own memory.