thanks anyway, i'll have a look at hprof, maybe it's already what i
need(?). i just need to find out what are the possible places for
references not being removed when an object is disposed.
stupid related question : the java collection classes probably all
work with internal caches, so for example ArrayList (or HashMap or
HashSet) will grow in steps and not on a per element base, and
there's probably an array in the background. is it possible that
after myArrayList.remove( anObject ) there is still some kind of
reference to that object in myArrayList that would prevent the gc
from disposing anObject ? (probably not, but i'm just curious)
My guess would be no as well. Checking the source might be useful.
But because a class has a cache of 10 elements has nothing to do with
an object being added and then removed being eligible for gc or not.
It just means increases in growth come less frequently but in larger
steps. What might be worth investigating is if the cache space is
ever reclaimed. Say you start out with an initial size of 10 and add
5 when you get the 11th. If you drop back down to 10 do you free up
the 5 again? Don't know. I suppose a whole lot of that with many
instances of non-gc'd collection instances could amount to a memory
leak as well.
Once it is removed from the collection, the collection should have no
bearing on whether a given object is retained. If it does hang onto a
reference preventing gc I think you've found a major bug.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden