Hello, 

In 2 words, the feature request is to add some kind of navigation to the references tree in the heap dump view.
I can see many ways to implement it:
1) Make search by keyword, so the tree nodes would appear one by one (for example like windows registry search is 
performed)
2) Apply filter to the tree, so it would only show those paths, which contain object instances of the specified class
3) Any other way

I do not care which of them would fit better to for the profiler - the main goal is to have the described ability.

Currently there is possibility to search the nearest gc root in the instances tree - this is close, but in most cases 
not enough.

this is a quote from the netbeans mailing list which describes the problem a bit better:

from  Anton Moiseev <benderamp@gmail.com>    hide details   Oct 28 (5 days ago) 
  to  users@profiler.netbeans.org   
  date  Oct 28, 2007 4:47 AM   
  subject  prifiler 6.0 heap dump reverences tree

I have tried profiler 6.0beta - it is really good. Especially the heap
dump's Instances/references view - it helps to find the exact source
of the memory leak (which were impossible without this view in 5th
version). For example, at some moment I know that the instance of
MyObject class should be garbage collected, but in the "live allocated
objects" view I can see, that this reference is live. So I make a heap
dump, open this object in Instances View, and in the "references view"
start expanding the referent tree nodes one by one trying to find the
object which holds the reference to MyObject instance and prevents it
from being garbage collected. If I know that in my program another
object of type PersistentObject should be alive at this moment, and if
would see this object at some level of the MyObject's "references
view" tree, I can understand, that this is the source of the memory
leak.
 What I really miss in profiler at this moment is effective tools for
working with the references view tree - for navigating through it and
finding the object of type that I need. For the above example,
MyObject is complex custom gui component, it has a big number a
anonymous classes defined inside it (listeners) which are registered
here and there, so the "references view" tree has a big number of the
following entries which can be expanded:
 -this$0
 -this$0
 -this$0
 ...
 -this$0


 The PersistentObject reference is somewhere under these nodes (and
not on the 1st level of deepness), but in order to find it I have to
look through 20 tree nodes like the above, recursively expanding each
node, one by one manually. This might take forever. If I had a simple
text field "filter", where I could put the name of the
PersistentObject class, so after applying it the referent tree would
only show me tree paths, which contain PersistentObject references,
this would save hours from manual routine work. This might be
implemented in some other way - like search engine or something else -
the main goal is to solve the described problem and to add some
automation for this tree. Are there any plans for improvements in this
area in some coming versions?

from  Gregg Sporar <Gregg.Sporar@sun.com>    hide details   Oct 29 (4 days ago) 
  reply-to  users@profiler.netbeans.org   
  to  users@profiler.netbeans.org   
  date  Oct 29, 2007 4:55 PM   
  subject  Re: [profiler] prifiler 6.0 heap dump reverences tree   
  mailed-by  profiler.netbeans.org   
Hello -

 >Are there any plans for improvements in this area in some coming versions?

I don't know of any specific plans, but if I understand correctly what
you are suggesting, it sounds like a useful feature.  You are asking for
a search feature that starts from a specific object instance and then
finds the nearest object of type "X" in the list of references - have I
got that right?  In any case, please enter an IssueZilla entry -
http://www.netbeans.org/issues/enter_bug.cgi.

FWIW, there is a feature in NetBeans 6.0 that *might* help in some
situations.  Right-click an entry in the References window of the
HeapWalker and choose "Show Nearest GC Root" from the context menu.  The
HeapWalker will start from that object and search through all references
to it until it finds the shortest path to one of the JVM's garbage
collection (GC) root objects.  Frequently the GC root object that it
finds will be something that is relatively obscure - a classloader
reference or something else that is not in your code.  The
user-interface expands all the references in the path that are along the
way to that GC root, however, and that is where it can get more
interesting.  There are many situations where you will see your own
objects along that chain of references.  In your case, if you see a
PersistentObject instance along the path of references to the GC root,
then the "Show Nearest GC Root" feature has saved you quite a bit of
time.  :-)

HTH,
Gregg