Leak suspect report [message #895768] |
Sun, 15 July 2012 17:38  |
Eclipse User |
|
|
|
Leak suspect report shows follwoing as the suspects. But my question is about the message at the bottom, which says that these are referenced from a WeakHashMap, so shoudn't these be garbage collected during the Full-GC phase?
279 instances of "hudson.plugins.cobertura.targets.CoverageResult", loaded by "java.net.URLClassLoader @ 0x2ac774988cc0" occupy 3,766,994,368 (19.67%) bytes.
Biggest instances:
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2aca4681d3b0 - 402,065,440 (2.10%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac956dfd440 - 401,219,936 (2.10%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2acac9dc2670 - 399,164,488 (2.08%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac927ac23a8 - 398,056,168 (2.08%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac9f06b5cd8 - 392,134,000 (2.05%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac97add0390 - 392,085,544 (2.05%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac8c300ffe0 - 375,067,880 (1.96%) bytes.
•hudson.plugins.cobertura.targets.CoverageResult @ 0x2ac7ef77b030 - 320,967,496 (1.68%) bytes.
These instances are referenced from one instance of "java.util.WeakHashMap$Entry[]", loaded by "<system class loader>"
|
|
|
Re: Leak suspect report [message #895815 is a reply to message #895768] |
Mon, 16 July 2012 03:48   |
Eclipse User |
|
|
|
Hi,
it will if spaces is required and it is well-implemented.
See implementation note from javadoc:
Quote:Implementation note: The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded. Note that a value object may refer indirectly to its key via the WeakHashMap itself; that is, a value object may strongly refer to some other key object whose associated value object, in turn, strongly refers to the key of the first value object. One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get.
Regards,
|
|
|
|
Re: Leak suspect report [message #899481 is a reply to message #896022] |
Wed, 01 August 2012 02:37  |
Eclipse User |
|
|
|
Hi,
The report just looks at the biggest objects, and tries to summarize some information about who is holding them.
The sentence may also mean that there are other paths, but the shortest ones go throug this WeakHashMap$Entry.
Explore the references to the objects, also execute paths from GC roots manually (there you can specify that weak paths are skipped).
You may find then strong references, or you may also observer what Aurélien suggested - some strong paths from the values to the keys of the map.
Hope this helps.
Krum
|
|
|
Powered by
FUDForum. Page generated in 0.05137 seconds