|Title||Culprit analysis is too hard.|
|Assigned user||Richard Brooksby|
|Description||Culprit analysis is too hard.|
By culprit analysis we mean finding out why the heap is too large, why
this object (or objects) is alive, and similar questions.
Culprit analysis would be useful for Configura .
|Analysis||The absolute minimum interface would be one where the client passes a|
reference to an object (managed by the MPS) to the MPS and asks "find
me an object that references this object".
Related issue is metadata about object and non-object addresses:
In general a reference to an object can be "encrypted" inside a client
object in an arbitrary manner. All the MPS knows is that an object had
a particular reference _somewhere_ inside it. The MPS should answer
the "find me an object that references this object" with: object, pool,
offset, client format specific userdata. The pool is necessary so that the
format can be derived. And whilst I just said that the MPS cannot know
the offset within an object, if the client scanner uses the very common
method of passing interior object addresses to MPS_FIX2 (that is,
pointing directly at the references stored inside the object), then the
MPS can spot this and generate its own offset. The userdata can be
used by the client for more complicated cases.
If we constrain the answer to be the object with lowest address larger
than some client specified address then we have an iteration protocol
to find all such objects.
Proposed interface in  and .
|Created by||David Jones|
|Created on||2007-06-04 12:58:55|
|Last modified by||Richard Brooksby|
|Last modified on||2013-06-16 07:13:09|
|History||2007-06-04 DRJ Created.|
2007-09-18 DRJ Linked to proposal.
2007-09-18 DRJ Link to branch
2013-03-19 GDR Assigned to RB.
2013-06-16 RB Downgraded to "optional" as this isn't affecting anyone (see job003499).