SOS.dll ObjSize and DumpObject under the hood intr

问题:

This question is largely based on my previous post found here.

I'm attempting to recreate some of the functionality of the SOS.dll using reflection. Specifically the ObjSize and DumpObject commands. I use reflection to find all the fields and then if the fields are primitive types I add the size of the primitive type to the overall size of the object. If the field is a value type, then I recursively call the original method and walk down the reference tree until I've hit all primitive type fields.

I'm consistently getting object sizes larger than SOS.dll ObjSize command by a factor of two or so. One reason I've found is that my reflection code seems to be finding fields that SOS is ignoring. For example in a Dictionary, SOS find's the following fields:

• buckets
• entries
• count
• version
• freeList
• freeCount
• comparer
• keys
• values
• _syncRoot
• m_siInfo

However my reflection code finds all of the above and also finds:

• VersionName
• HashSizeName
• KeyValuePairsName
• ComparerName

Also, I'm getting confused regarding the inconsistencies found in the SOS ObjSize and DumpObject commands. I know DumpObject doesn't look at the size of the referenced types. However when I call Object size on the dictionary mentioned above I get:

• Dictionary - 532B

Then I call DumpObject on the Dictionary to get the memory address of it's reference types. Then when I call Objsize on it's reference types I get:

• buckets - 40
• entries - 364
• comparer - 12
• keys - 492
• (the rest are null or primitive)

Shouldn't the ObjSize on the top level dictionary roughly be the sum of all the ObjSizes on fields within the dictionary? Why is Reflection finding more fields that DumpObject? Any thoughts on why my reflection analysis is returning numbers larger than SOS.dll?

Also, I never got an answer to one of my questions asked in the thread linked above. I was asking whether or not I should ignore properties when evaluating the memory size of an object. The general consensus was ignore them. However, I found a good example of when a property's backing field would not be included in the collection returned from Type.GetFields(). When looking under the hood of a String you have the following:

Object contains Property named FirstChar Object contains Property named Chars Object contains Property named Length Object contains Field named m_stringLength Object contains Field named m_firstChar Object contains Field named Empty Object contains Field named TrimHead Object contains Field named TrimTail Object contains Field named TrimBoth Object contains Field named charPtrAlignConst Object contains Field named alignConst The m_firstChar and m_stringLength are the backing fields of the Properties FirstChar and Length but the actual contents of the string are held in the Chars property. This is an indexed property that can be indexed to return all the chars in the String but I can't find a corresponding field that holds the characters of a string.

Any thoughts on why that is? Or how to get the backing field of the indexed property? Should indexed properties be included in the memory size?

回答1:

Well, your Reflection code is broken. The 4 members you mention (VersionName etc) are not fields, they are private constants. I'm guessing you are using Type.GetMembers() instead of Type.GetFields() and not checking the returned MemberInfo.MemberType properly. Just use GetFields() instead.

Do note that you can never get the correct size of a managed object. The layout of the object is undiscoverable. The size is not the sum of the fields, fields are aligned. Pretty similar to the StructLayout.Pack property. Alignment can create holes in the layout, so-called "padding bytes". As well as extra padding at the end to get fields aligned when the class object is stored in an array.

The fact that layout is not discoverable is actually taken advantage of by the CLR. It will swap fields if a later field fits in the padding between two other fields. Producing a smaller object than what you'd get if you knew the alignment rules. Trying to reverse-engineer this is a perilous endeavor, it also depends on the architecture (x86 vs x64 vs Arm).

SOS.dll doesn't have that problem, it has direct access to the internal data that the CLR maintains for a class. Off limits to managed code.