diff --git a/mps/code/mpmst.h b/mps/code/mpmst.h
index b1367b0f92d..ac2bf47b602 100644
--- a/mps/code/mpmst.h
+++ b/mps/code/mpmst.h
@@ -201,19 +201,13 @@ typedef struct MessageClassStruct {
/* methods specific to MessageTypeGC */
MessageGCLiveSizeMethod gcLiveSize;
- /* methods specific to MessageTypeGC and MessageTypeGCGen */
+ /* methods specific to MessageTypeGC */
MessageGCCondemnedSizeMethod gcCondemnedSize;
MessageGCNotCondemnedSizeMethod gcNotCondemnedSize;
/* methods specific to MessageTypeGCStart */
MessageGCStartWhyMethod gcStartWhy;
- /* methods specific to MessageTypeGCGen */
-#if 0 /* @@@@ */
- MessageGCGenNameMethod gcGenName;
- MessageGCGenForwardMethod gcGenForward;
-#endif
-
Sig endSig; /*
These messages are generated once per GC at the end of a GC.
(new in gcgenmsg branch) These messages are generated once - per generation per GC. A single such message explains how a generation - intends to participate in the collection. They are useful to experts - and interesting to other parties.
The intended readership is project staff.
@@ -85,7 +78,8 @@ here.MPS staff must be able to tell what collections are happening - in order to be able to introspect about the overall MPS process.
+ in order to be able to introspect about the overall MPS process. +This is so that bugs can be diagnosed and general MPS behaviour can be @@ -99,12 +93,30 @@ here.
We intend to meet that requirement by implementing a message -that is generated per generation per collection -(mps_message_type_gc_generation) and a message that is generated per +
We meet part of that requirement by implementing + a message that is generated per collection (mps_message_type_gc_start).
-We have the +
We have the following requirements on per GC messages:
+ +Must be able to tell why we are starting a collection. See + job000666 for why we start collections.
This section for historical interest only.
+ +A proposal to meet the full requirement by implementing a message +that is generated per generation per collection +(mps_message_type_gc_generation) +has not been implemented, +but the requirements have been retained here:
+ +We would have the following requirements on per generation messages:
We have the following requirements on per GC messages:
- -Must be able to tell why we are starting a collection. See - job000666 for why we start collections.
Message in this class will support:
- -identification; each generation will be identified by - (pool class, pool serial number, generation serial number).
get condemned size
get non-condemned size
get forwarding gen
Condemned size / not condemned size correspond to accessors for -MPS_MESSAGE_TYPE_GC as well. We could have some sort of collectable -class that has both the existing "gc" and the new "gc generation" type -as sublcasses, but I don't think I'll bother for now.
- -A message instance will be associated with a generation structure. -Specifically the PoolGenStruct; there is one of these per generation -in a pool that uses Chains for collection policy management. The -message struct will be a member of PoolGenStruct to simplify memory -management as per the general message design. -
- -Choice: could put all the actual info in the PoolGenStruct and have -a generic message member (this is simplest if only PoolGenStruct wants -to implement the message) or could create a new gcgen message struct and -embed that in PoolGenStruct (which allows other parts of the MPS to -implement the message).
- -For now we will put the info (condemned size, etc) in the -PoolGenStruct and embed a generic message structure. As per the trace -design, there will be a new intermediate struct, private to the PoolGen -module, that contains the info required for the message. -PoolGenMessageStruct.
- -There will only be one message and set of info per generation. -Generally data will refer to the most recent trace; multiple concurrent -traces are not very well suported by this design.
-int mps_message_type_gc_generation()Public interface. Returns the message type for gc gen - messages.
const char *mps_message_gc_generation_name(mps_arena_t,
- mps_message_t) Public interface. Returns a string pointer that identifies
- this generation. The contents of the string shall not be modified by
- the client. The string and the pointer are only valid as long as the
- message has not been discarded (with
- mps_message_discard).
The string should be of the form: "[" pool-class ":" - pool-instance-number "," generation-number "]"
size_t mps_message_gc_generation_condemned_size(mps_arena_t,
- mps_message_t)Public interface. Reports the number of condemned bytes in - this generation for this collection. May be an estimate.
size_t mps_message_gc_generation_not_condemned_size(mps_arena_t,
- mps_message_t)Public interface. Reports the number of bytes occupied by - objects in this generation that are not condemned for this collection. - May be an estimate.
const char
- *mps_mesage_gc_generation_forward(mps_arena_t,
- mps_message_t) Public interface. Returns a string pointer that identifies
- where survivors from this generation are being forwarded to. The
- contents of the string shall not be modified by the client. The
- string and the pointer are only valid as long as the message has not
- been discarded (with mps_message_discard).
Generally this string will identify a generation and should be in
- a similar form to the id string (returned by
- mps_message_gc_generation_id
MPS_MESSAGE_TYPE_GC_GENERATION Private interface. An enum member that identifies the message - type.
int mps_message_type_gc_start() Public interface. Returns the MPS message type.
mps_message_discard).
- There needs to be an interface between the implementation of the - gc generation messages (which is expected to be PoolGen in locus.c) - and the Pool Classes in order that the information contained in the - message can be gathered.
- -Pool Classes condemn objects on a - segment-by-segment basis; it seems most natural for PoolGen to keep a - condemned bytes counter and for the Pool Class to update this counter - as it condemns objects. The number of not-condemned bytes can be - estimated by PoolGen as (totalSize - condemned).
- -PoolGen knows the pool and the serial number so can id the - generation without involving anyone else.
- -The forwarding generation will have to be filled in by the Pool - Class. Message can hold a fixed size char buffer that the pool class - can fill with textual description.