FULL PRODUCT VERSION :
Java HotSpot(TM) 64-Bit Server VM; 1.7.0_11; 23.6-b04; mixed mode

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.2.9200]

A DESCRIPTION OF THE PROBLEM :
TCPEndpoint class has a static variable:

    /** maps an endpoint key containing custom socket factories to
     * their own unique endpoint */
    // TBD: should this be a weak hash table?
    private static final
        Map<TCPEndpoint,LinkedList<TCPEndpoint>> localEndpoints =
        new HashMap<TCPEndpoint,LinkedList<TCPEndpoint>>();

That holds on the localEndpoints which are isntances of TCPEndpoints
This map is never cleared for example when i do an unexport(remote,true)

Also the comment there: // TBD: should this be a weak hash table?
is already telling that the guy who wrote this did see this as a potential problem.

The case is this, we have a WAR file with our classes there we also have rmisocketfactories that we use to export Remote objects with. When undeploying this War application we force a:

UnicastRemoteObject.unexportObject(remote, true);

of all our exported remote object, this seems to work well, but the TCPEndpoints still keep referring to the 2 socketfactories we specified when we did a exportObject.
Those socket factories are loaded by the WebappClassLoader of the app srever so that instance is never released,, so a few redeployes and we get a:

Caused by: java.lang.OutOfMemoryError: PermGen space

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A simple servlet that on init does an export with some special RMISocket factories and on destroy an unexport of that same remote object

Then a heap dump will show that the webappclassloader is still there because of the static reference of TCPEnpoints.localEndpoints map.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That those are somehow cleaned, maybe with unexport then remove them, they are not needed anymore.

Or have some weak references for that, But i am not sure which strong reference is then holding on to it when the app is just deployed.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
there is no workaround for this, i don't see anyway that i can clear this map myself.