In-heap debugging padding/metadata

[steveblackburn]

To assist in debugging GCs, inject padding before and after each allocated object.

At its simplest, when this feature is enabled, the padding will contain magic numbers which will be evident when dumping heap contents during debugging (in a debugger), because the peculiar bit patterns embedded in each header and footer will betray the start and end of each object (as long as the heap has not been corrupted).

More advanced variations on this idea have the padding containing (redundant) metadata such as the object size, location of pointers, etc, which would allow the mmtk-core to do some basic integrity checks on any such object without having to rely on a VM binding (which is how we normally find pointers in objects and find objects' sizes). This means that the mmtk-core can have its own self-contained heap integrity checks which are quite independent of any bindings or any other language-specific assumptions.

Once such padding is in place, a variety of integrity assertions should become straightforward. For example, when this is enabled, the integrity of an object reference can always be checked because any non-null object reference should point to a region of memory contained within such a header and footer. The absence of these would suggest a corrupt object reference.

Attribution: This idea was shared with me by Göran Rydqvist, who has implemented it in his VM.

[wks]

CRuby, when in debug mode, appends a field to every object to hold the "Ractor ID" to identify the Ractor that owns that object. It is used by assertions in various places.

JVM TI allows the user to assign a "tag" (of jlong type) to each object so that it can enumerate all objects with a given tag. But OpenJDK implements this using a global hash map (JvmtiTagMap) protected by a mutex.