J2SE Version (please include all output from java -version flag):
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b58)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b58, mixed mode, sharing)
RFE: ability to find out a strongly reachable chain
This RFE is for use at development time in order to trace down memory
leaks
(performance of this method does not matter).
What I would like is the ability
to pass in an Object to a method and
get a List of Objects back that make the
passed in Object strongly
reachable.
In general the result would have a Thread at one end of the List and the
passed in Object at the other.
If the Object is strongly reachable in more than
one way, only one way
needs to be returned.
Alternatively if we had a way to find out which Objects were directly
reachable from a given thread we could implement this method ourselves,
and also produce heap dumps to find out exactly what is in memory and
hence what is causing the OutOfMemoryErrors.
Some external profiling tools allow us to do some of this, however in
general we can not use these at client sites and have almost no control
over how java is run there, and furthermore we would only want to know
this information when there is a problem (always running these tools
slows things down by too much).
I have seen a lot of Sun developers trying to solve memory leak
problems, that would be much simpler to solve with a method such as this.
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b58)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b58, mixed mode, sharing)
RFE: ability to find out a strongly reachable chain
This RFE is for use at development time in order to trace down memory
leaks
(performance of this method does not matter).
What I would like is the ability
to pass in an Object to a method and
get a List of Objects back that make the
passed in Object strongly
reachable.
In general the result would have a Thread at one end of the List and the
passed in Object at the other.
If the Object is strongly reachable in more than
one way, only one way
needs to be returned.
Alternatively if we had a way to find out which Objects were directly
reachable from a given thread we could implement this method ourselves,
and also produce heap dumps to find out exactly what is in memory and
hence what is causing the OutOfMemoryErrors.
Some external profiling tools allow us to do some of this, however in
general we can not use these at client sites and have almost no control
over how java is run there, and furthermore we would only want to know
this information when there is a problem (always running these tools
slows things down by too much).
I have seen a lot of Sun developers trying to solve memory leak
problems, that would be much simpler to solve with a method such as this.
- relates to
-
JDK-5059757 RFE: forced garbage collect of an object for classloader issues
-
- Open
-