Fully featured low overhead profiler for Java EE and Java SE platforms.
Ultimate profiling and monitoring solution for Gradle, Maven, Ant, JUnit and TestNG.
Easy to use performance and memory profiler for .NET framework.

Reference groups

Moderators: Vladimir Kondratyev, Anton Katilin

Reference groups

Postby tbehrends » Thu Sep 09, 2004 7:12 pm


I am mainly profiling the memory consumption of my application. Whenever I see there is a load of object of a specific class (e.g. String) I'd like to analyse wherefrom this objects a referenced (especially if the number of objects of this class increased dramatically since the last profile).

It's only possible to analyze single objects with the "Find Path" function and then only to see the first n objects (which are never the interesting ones ;-). More interesting would be to see which _percentage_ of the objects are referenced by which other class (not objects). Than I could see x% are referenced by class A, y% by class B and so on.

Any plans to implement something like this?

Posts: 16
Joined: Fri Sep 03, 2004 2:38 pm

Postby Vladimir Kondratyev » Fri Sep 10, 2004 10:23 am

We think that there is a different approach which prevents from solving the described task. If we properly understanded you, first you find class with biggest number of instances and after that you are trying to classify where these instances are referenced from.

There is another approach that is already provided by "Class Tree" view. You start with the whole number of objects and drilling down package tree, find your subsystem (usually subsystem corresponds to package) that retains the most amount of memory.
Vladimir Kondratyev
Posts: 1447
Joined: Tue Aug 10, 2004 7:52 pm
Location: Düsseldorf, Germany

Postby tbehrends » Sat Sep 11, 2004 11:36 am


Finding the class with the biggest amount of memory (using the package explorer) is only the first step.

When I see that the number of objects has increased since my last memory-snapshot I would like to know where the objects are referenced from and why (if there is a memory leak) they are not deleted by the garbage collector.

Using the path-function is one way to look for references but it only works with a small number of objects and gives no overview.
Posts: 16
Joined: Fri Sep 03, 2004 2:38 pm

Postby Anton Katilin » Mon Sep 13, 2004 7:15 am

To find the new objects you can use snapshot comparison feature. Then select new objects and find paths to see why the new objects retain.
Anton Katilin
Posts: 5613
Joined: Wed Aug 11, 2004 8:37 am

Postby tbehrends » Mon Sep 13, 2004 7:27 pm


Thats the problem: I have to checks each single object and I can only check the first 100 or 1000 but I my case I have 12000 remaining. I would prefer more "overview".

Posts: 16
Joined: Fri Sep 03, 2004 2:38 pm

Return to Java Profiler

Who is online

Users browsing this forum: No registered users and 10 guests