This page gives a short overview to the runtime object layout for Eiffel Systems compiled with Eiffel Studio.
An object in memory needs to hold different information. First of all the current values of its attributes and the dynamic type id of the object. Besides that, the garbage collection needs some additional information saved per object.
The object layout has to provide both fast access to the attributes and the garbage collector (gc) with a way to explore all the reference fields of an object. The latter is important during the marking phase of the gc.
The following picture shows the principal object layout chosen for EiffelStudio:
The picture shows, that a reference to an object points to the first attribute of the object. The object actually starts earlier. The part of the object that comes prior to the fields is called the overhead. The overhead contains the type id of the object and some additional information for the garbage collector.
The picture furthermore shows that the attributes of a reference type come first. As a result of that, the garbage collector only needs to know how many references the object contains to traverse its suppliers. Fields of primitive expanded types are hold at the end of the object. Their layout is not covered here.
The chosen memory layout has a very important property. To access an attribute of an object, the dynamic type of the object needs to be known. The following picture shows the effective memory layout for an EiffelSystem composed of classes A and B:
Attribute a1 has a different relative position in memory for objects of class A or B. So when accessing a1 of an object the exact type of the object needs to be known.