[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mat-dev] BHeapSampler memory analysis tool made public
- From: Markus Kohler <markus.kohler@xxxxxxxxx>
- Date: Wed, 16 Nov 2011 10:57:59 +0100
- Delivered-to: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xykrf+NGMIvOblP6uG8gjGhMPqp31i39HPWcFLPsRxA=; b=TLhpWji17VM13C+rBG/nK5rXrP7crSbO4rr2DaTqxQkxrM03OpOLQSgZFzwIZyHcRS US8Ou3EWDnsrpfy7UNR16te9VrkMDe6Ipa9e6R9ivj1LKecBw98WoXfPYZKRxfCB3rXr gMVxCFOVtH9kXzwxKNDvPda9LjH+uBypXfFXk=
I believe that one can compute a approximated class level graph out
of the dominator tree.
I will try to do a prototype, in order to proof that its possible.
On Tue, Nov 15, 2011 at 10:06 PM, Arndt <Arndt.244488@xxxxxxxxxxx> wrote:
> Hi Markus, Andrew,
> some thoughts on your comments:
>>> The Sampling approach always seemed interesting to me, but I only
>>> thought about approximating certain memory usage indicators.
> From the understanding that I have now, statistical sampling is the biggest
> problem of my approach. Statistical error is a problem, especially when
> looking for differences between two heapdumps, and the fact that I have
> classes with multiple nodes in the graph (e.g. String, ArrayList, ...), but
> only the total instance count for these classes (no per-node instance
> counts) also is a direct consequence of the statistical approach.
> I now think that that one could get a better result via an exact calculation
> in a comparable amount of processing time.
>>> I do not 100% understand how you compute the the memory usage, could you
>>> elaborate that a bit more?
> I just count memory-paths. If you calculate 10 memory-paths per Megebyte
> total size, than you can add 1/10 MB to every node that this path includes.
> But prevent double counting: some memory-path contain a class multiple times
> (e.g. in linked lists), in that case add the 1/10 MB to that class only
>>> Are you aware that MAT has a feature in the Dominator tree that allows
>>> you to group by
>>> class (or package)? I believe one could build an approximated "memory
>>> domination graph"
>>> by using the data from this view.
> I understand that I can view any subtree of the dominator tree as a list of
> cummulated shallow-sizes of the participating classes. But I don't see how
> that can replace the class-level graph-view. Think about an evil structure
> with the shallow size mainly in Strings, but located all over in the smaller
> "branches" of the dominator tree. In the tree view, it's below noise level,
> but in a class-level-graph, it will pop up as hotspot.
> mat-dev mailing list