mmartin@cs.tcd.ie (Maurice Martin) (04/16/91)
Background: Using the normal memory management routines on the DEC5810
MIPS implementation of Eiffel (i.e. 32 bit word size), each
object has a 64 bit object header, defined by the following
struct:
OBJECT = struct {
INFO info ; -- INFO == int32
struct OBJECT* nobj;
}
Question: Apart from garbage collection, what is the pointer ``nobj''
used for ?
Partial Answer: It appears as if all objects in an eiffel system are
chained together via the nobj field. This is used during
garbage collection. Also the environment and storable
classes seem to reference the field. It also appears to be
used in connection with EXPANDED classes. I do not
follow exactly how nobj and expanded classes inter-relate.
-- If I have got `nobj's uses wrong, or missed some, please correct me!
Thanks in Advance,
=======================================================================
Maurice Martin email: mmartin@cs.tcd.ie
Distributed Systems Group fax : + 353-1-772204
O'Reilly Institute, T.C.D. phone: + 353-1-772941 x1524 (day)
Dublin 2, IRELAND. + 353-1-462681 (evening)
========================================================================rick@tetrauk.UUCP (Rick Jones) (04/17/91)
In article <1991Apr15.170027.8088@cs.tcd.ie> mmartin@cs.tcd.ie (Maurice Martin) writes: > >Background: Using the normal memory management routines on the DEC5810 > MIPS implementation of Eiffel (i.e. 32 bit word size), each > object has a 64 bit object header, defined by the following > struct: > > > OBJECT = struct { > INFO info ; -- INFO == int32 > struct OBJECT* nobj; > } > >Question: Apart from garbage collection, what is the pointer ``nobj'' > used for ? > >Partial Answer: It appears as if all objects in an eiffel system are > chained together via the nobj field. This is used during > garbage collection. Also the environment and storable > classes seem to reference the field. It also appears to be > used in connection with EXPANDED classes. I do not > follow exactly how nobj and expanded classes inter-relate. You're right in what you've said. In fact, the memory management keeps two lists - one of active objects and one of free objects. When objects are collected, they move onto the free list with adjacent free objects being merged together to minimise fragmentation. New objects are "cut out" of the free list to the correct size and put into the active list (if the free list runs out, more space is malloc'd). An expanded object is an embedded part of a normal object, so is not chained onto the allocated list. Instead, its nobj pointer points to the enclosing object, and a bit in the info field identifies it as expanded. Since the garbage collector cannot directly free an expanded object, it is only interested in the outer enclosing object - so when following references for marking, when it finds a reference to an expanded instance it chases the nobj pointers until it arrives at the containing object, and marks that. The environment and storable mechanisms use basically the same algorithm as the garbage collector to determine a network of connected objects. BTW, I understand that the implementation of expanded objects will change with version 3, but I don't know the details. ISE might like to comment? -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Any fool can provide a solution - the problem is to understand the problem