jmx-dev JMX RMIConnectionImpl Memory "Leak"

[Benedict Elliott Smith]

Hi,

Introduced in this webrev:
http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/985b53122cf8

The CombinedClassLoader introduced here resolves any classes it loads
against itself, or its ClassLoaderWrapper wrapped defaultCL, as opposed to
its parent or the defaultCL directly. This appears to be deliberate, and I
assume is to avoid classes remaining loaded when they are no longer needed
by JMX. However the result is that every time a JMX method is invoked, or a
new connection is established (or a number of other actions are taken), any
classes not already loaded in the context class loader are repeatedly
loaded and resolved against a different CL.

The upshot of this is that the permgen gets rapidly filled with these
classes. The end result of which is that the VM can OOM under very low load
and very low heap utilisation, as unless you are generating enough garbage
to trigger a full GC these classes will not be collected.

The workaround is to introduce the CMSClassUnloadingEnabled flag, but it
seems to me that the problem would be better addressed at the source, as
this is fairly undesirable behaviour.

It seems that, if the desire is to reduce wasted memory from classes loaded
for JMX but not used by the rest of the VM, the best solution might be to
map the original class loaders to a SoftReference to a shared wrapping
class loader for that pair. This should retain the current behaviour of not
resolving against the original class loaders whilst ensuring we don't
proliferate many class loaders with the same classes.

Alternatively, if the reason for these wrappers is simply to perform
proxying, I would suggest that simply resolving against the original CLs
would be preferable. I can't see why loading these classes against the
original CLs would be so detrimental, but I may be missing something.

I'd be happy to submit a patch for this if a preferred solution can be
reached.

Thanks,

Benedict
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20140204/c21ac4ec/attachment.html