Here is the block diagram that I referred to: http://staff.develop.com/jasonw/weblog/rotorobject.jpg
This shows the relationships between the various structures that you will encounter within the rotor codebase. > -----Original Message----- > From: Discussion of the Rotor Shared Source CLI > implementation [mailto:[EMAIL PROTECTED] On > Behalf Of David Stutz > Sent: Wednesday, April 02, 2003 9:26 AM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET-ROTOR] types in the CLR > > > The relationships of the different structures are a little > bit complex; we've written a lot of this kind of detail down > in the book "Shared Source CLI Essentials" from O'Reilly that > is now available. In particular, there is a map that shows > the relationship of all of the various type and object > headers that would probably be valuable to you. If I'm not > mistaken, this map is also online, but I am on the road right > now and can't remember the URL. Anyone else on this list able > to jog my memory? > > -- David > > > -----Original Message----- > > From: Discussion of the Rotor Shared Source CLI implementation > > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Cohen > > Sent: Wednesday, April 02, 2003 7:50 AM > > To: [EMAIL PROTECTED] > > Subject: [DOTNET-ROTOR] types in the CLR > > > > > > Hi, > > > > I've been doing some research on the shared source CLI (Rotor), > > specifically looking at how types that are loaded in the CLR are > > represented. From my current understanding, every type that > is loaded > > into an application domain by the ClassLoader class is > represented by > > an EEClass [class.h]. Each EEClass has a pointer to a MethodTable > > class [class.h] that stores the v-table and a map to > interfaces that > > the class inherits from. So the MethodTable is basically what > > defines a type in memory. > > > > >From my understanding, when an instance of a type is > instantiated, a > > >new Object class [object.h] is created that represents the > > instance of > > >the type. This Object also contains a pointer to the MethodTable. > > > > To help further my understanding of how types are laid out > in memory I > > read Don Box's book "Essential .NET Volume 1: The Common Language > > Runtime". On page 80, Box proceeds to explain the CLR object header > > and a structure called the CORINFO_CLASS_STRUCT. > > > > The object header contains a sync block, a handle representing the > > object's type, and the object's fields. I did find an > ObjHeader class > > [syncblk.h] that contains a member called m_SyncBlockValue, but it > > does not contain a handle or array of fields. Does anyone > know how the > > ObjHeader class, Object class, and fields are actually laid out in > > memory and also where this occurs in Rotor? My guess is that > > the type handle is the pointer in the Object class pointing > > back to the MethodTable. > > > > Box explains that the CORINFO_CLASS_STRUCT structure > contains several > > pieces of information that defines the type. The type handle in the > > object header points to this structure. Within Rotor, I found a > > COR_INFO_CLASS_HANDLE [corinfo.h] that is typed defined as struct > > CORINFO_CLASS_STRUCT_*. Based on this newfound knowledge, > I've become > > a little confused about how the CORINFO_CLASS_HANDLE and the > > MethodTable class are related to each other. Does anyone know the > > details of how the CORINFO_CLASS_HANDLE is used in the > runtime and how > > it relates to the MethodTable class? > > > > Finally, when there is a managed reference to an object in the > > runtime's managed heap, is the reference wrapped in the OBJECTREF > > class [vars.hpp]? The OBJECTREF class does contain a > pointer m_asObj > > that points to an Object class. > > > > Thanks in advance to anyone that can help me. > > > > Michael Cohen > > > > > > -------------------------------------------------------------- > > -------------- > > This electronic message transmission contains information > that may be > > confidential or privileged. The information contained herein is > > intended solely for the recipient and use by any other party is not > > authorized. If you are not the intended recipient (or otherwise > > authorized to receive this message by the intended recipient), any > > disclosure, copying, distribution or use of the contents of the > > information is prohibited. If you have received this electronic > > message transmission in error, please contact the sender by reply > > email and delete all copies of this message. Cigital, Inc. > > accepts no responsibility for any loss or damage resulting > > directly or indirectly from the use of this email or its > > contents. Thank You. > > -------------------------------------------------------------- > > -------------- > > > > > >
