8. Finalization¶
8.1. Overview¶
Finalization is implemented internally using the Guardian Pool Class
(design.mps.poolmrg). Objects can be registered for
finalization using an interface function (called
mps_finalize()). Notification of finalization is given to the
client via the messaging interface. PoolClassMRG
(design.mps.poolmrg) implements a Message Class which
implements the finalization messages.
8.2. History¶
.hist.0: Incomplete design. David Jones, 1997-02-14.
.hist.1: Converted from MMInfo database design document. Richard Brooksby, 2002-06-07.
.hist.2: Converted to reStructuredText. Gareth Rees, 2013-04-13.
8.3. Requirements¶
.req: Historically only Dylan had requirements for finalization, see req.dylan.fun.final. Now (2003-02-19) Configura have requirements for finalization. Happily they are very similar.
8.4. Architecture¶
8.4.1. External interface¶
-
mps_res_t
mps_finalize(mps_arena_t arena, mps_addr_t obj)¶
.if.register: Increases the number of times that the object
located at obj has been registered for finalization by one. The
object must have been allocated from the arena (space). Any
finalization messages that are created for this object will appear on
the arena’s message queue. The MPS will attempt to finalize the object
that number of times.
-
void
mps_definalize(mps_arena_t arena, mps_addr_t obj)¶
.if.deregister: mps_definalize() reduces the number
of times that the object located at obj has been registered for
finalization by one. It is an error to definalize an object that has
not been registered for finalization.
.if.deregister.not: At the moment (1997-08-20) mps_definalize() is not implemented.
-
void
mps_message_finalization_ref(mps_addr_t *mps_addr_return, mps_arena_t mps_arena, mps_message_t mps_message)¶
.if.get-ref: mps_message_finalization_ref() returns
the reference to the finalized object stored in the finalization
message.
8.5. Implementation¶
.int.over: Registering an object for finalization corresponds
to allocating a reference of rank FINAL to that object. This reference
is allocated in a guardian object in a pool of PoolClassMRG
(see design.mps.poolmrg).
.int.arena.struct: The MRG pool used for managing final references is kept in the Arena (Space), referred to as the “final pool”.
.int.arena.lazy: The pool is lazily created. It will not be created until the first object is registered for finalization.
.int.arena.flag: There is a flag in the Arena that indicates whether the final pool has been created yet or not.
.int.finalize.create: Creates the final pool if it has not been created yet.
.int.finalize.alloc: Allocates a guardian in the final pool.
.int.finalize.write: Writes a reference to the object into the guardian object.
.int.finalize.all: That’s all.
.int.finalize.error: If either the creation of the pool or the allocation of the object fails then the error will be reported back to the caller.
.int.finalize.error.no-unwind: This function does not need to do any unwinding in the error cases because the creation of the pool is not something that needs to be undone.
.int.arena-destroy.empty: ArenaDestroy() empties the
message queue by calling MessageEmpty().
.int.arena-destroy.final-pool: If the final pool has been
created then ArenaDestroy() destroys the final pool.
.access: mps_message_finalization_ref() needs to
access the finalization message to retrieve the reference and then
write it to where the client asks. This must be done carefully, in
order to avoid breaking the invariants or creating a hidden root.
.access.invariants: We protect the invariants by using
special routines ArenaRead() and ArenaPoke() to read
and write the reference. This works as long as there’s no
write-barrier collection. [Instead of ArenaPoke(), we could
put in an ArenaWrite() that would be identical to
ArenaPoke(), except for AVERring the invariant (or it can
just AVER there are no busy traces unflipped). When we get
write-barrier collection, we could change it to do the real thing, but
in the absence of a write-barrier, it’s functionally identical to
ArenaPoke(). Pekka 1997-12-09]
