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
