I'm trying to figure what might be referenced set from uncollected objects in permgen.
(We have a situation where large portions of the heap are reported as garbage by the heap analysis tools, but uncollected by CMS. One theory is that the garbage may be referenced by uncollected permgen objects)
permgen mostly has Class objects, so I've gotten this far:
SELECT AS RETAINED SET * FROM "java.lang.Class" s WHERE s.@GCRootInfo = null
but I'm not quite sure what the RETAINED SET includes. is it conservative in this calculation? If I calculated the full reachability of these class objects and their references would the result be any different?
I found my way to something like this:
SELECT AS RETAINED SET * FROM OBJECTS (
SELECT DISTINCT OBJECTS outbounds(f) FROM OBJECTS (
SELECT DISTINCT OBJECTS outbounds(e) FROM OBJECTS (
SELECT DISTINCT OBJECTS outbounds(d) FROM OBJECTS (
SELECT DISTINCT OBJECTS outbounds(c) FROM OBJECTS (
SELECT * FROM "java.lang.Class" s WHERE (s.@GCRootInfo = null)
Which is awkward at best.. It does, however, report a larger retained size than the first query, which hints that the reachability is larger than the retained set.. perhaps the difference is whether the objects are reachable from other gc roots?
So what exactly does the retained set include?
Assuming that the retained set is different from the reachable set, is there a way to calculate the reachable set?
Ah, thanks for the explanation of how the retained set is calculated.
Thanks too for the link to 309646, considering a reachability function. It suggests that raw reachability is useless because objects implicitly reference class loaders and class loaders reference everything.
In this case, we were trying to isolate the potential memory impact from the references of a set of objects, without distortion of contingent references from other roots. It would be nice to be able to compare this 'potential retained set' to the currently retained set.
In other words, I think it would be useful to have a way to get an upper bound on the amount of heap that an object might retain. A version of reachability that doesn't follow implicit references would be useful for this, and was suggested as a possibility in 309646, but not yet implemented.