I am trying to understand information stored in the method table. Here is my code.
class MyClass
{
private int x = 60;
private int y = 90;
public void MethodB()
{
Console.WriteLine("MethodB");
}
public void MethodC()
{
Console.WriteLine("MethodC");
}
public void MethodA()
{
GetHashCode();
Monitor.Enter(this);
Console.WriteLine("Attach debugger now");
Console.ReadKey();
}
static void Main(string[] args)
{
MyClass mc = new MyClass();
mc.MethodA();
}
}
Here is how object looks in memory
0:000> !do 0x02368a1c
Name: ConsoleApplication1.MyClass
MethodTable: 001f3310
EEClass: 001f136c
Size: 16(0x10) bytes
(C:\Download\PresentationPrep\TechDaysDemos\SomeTesting\bin\Debug\SomeTesting.exe)
Fields:
MT Field Offset Type VT Attr Value Name
6d032da0 4000001 4 System.Int32 1 instance 60 x
6d032da0 4000002 8 System.Int32 1 instance 90 y
Then I dump the method table
0:000> dd 001f3310
001f3310 00000000 00000010 00050011 00000004
001f3320 6d030770 001f2f2c 001f334c 001f136c
001f3330 00000000 00000000 6cf86ab0 6cf86ad0
001f3340 6cf86b40 6cff7540 008500d0 00000080
001f3350 00000000 00000000 00000000 00000000
001f3360 00000000 00000000 00000000 00000000
001f3370 00000000 00000000 00000000 00000000
001f3380 00000000 00000000 00000000 00000000开发者_开发知识库
Here is what I am finding a bit confusing.
The first field indicates type of object ( if its a class or array etc). My understanding is that for class this field displays
0x00040000
whereas here its displaying just0x00000000
.The second field is the size of the object. This one is OK.
What is the significance of third field
00050011
?This one indicates number of inherited methods, which points to parent object class methods
ToString
,Equals
,GetHashCode
andFinalize
. Is this correct?
I don't understand rest of the fields, so if some explain those also, it will be highly appreciated.
This is basically an implementation detail and trying to figure out how the CLR works by poking around the internal structures is not easy to say the least. A lot of the internal structures are optimized in various ways, which makes dumping the relevant information hard. I have a similar question here.
If you haven't already looked at it, I recommend you read Shared Source CLI essentials. While it doesn't cover all the gory details, it does give a pretty good explanation of how the shared source CLI is organized.
In my experience some of these structures cannot easily be mapped without the use of utility methods that encapsulates what the CLR is doing internally. That is basically what SOS does for us. If you get the source for the SSCLI, you can dig into the source for the shared source version of SOS for additional details.
Of course the SSCLI isn't the same as the current Microsoft CLR, but in my experience they have a lot in common, so it is usually a good source of information.
There's a detailed write up of how the method table was implemented in .NET 1.x here. It has a lot of details, but alas the implementation has been changed so it isn't valid for the current CLR.
Just use
!sos.dumpmt 001f3310
This will give you the Method table dump, and you dont have to worry about internal memory layout that can change between versions and SPs
精彩评论