A small ClassLoader change proposal

[Jevgeni Kabanov]

Bob, if you check the link to the blog post, it described such an implementation that I did a while ago. Unfortunately what I found out is that it doesn't work with some class loaders. Mainly because there are class loaders that at some point in their life cycle will throw an exception when a loadClass() is issued, and even if you use defineClass() a loadClass() is still issued for java.lang.Object when defining your class for the first time, causing an exception. So in the end I'm not using that code either, but I would be using it if it was safe.

On 16.09.2010, at 17:13, Bob Lee wrote:

> Jevgeni,
> 
> The best long term solution for the VM is ephemerons. They're not slated for Java 7 or even 8 yet though.
> 
> I implemented "class loader locals" as a library years ago. Unfortunately, I don't have the code anymore because I didn't end up using them.
> 
> The internals went something like this:
> 
> public class ClassLoaderLocals {
>   public static final Map values = new ConcurrenHashMap(); 
> }
> 
> (I used synchronization at the time.)
> 
> Now, force each ClassLoader to load its own copy of ClassLoaderLocals. If you reflectively invoke defineClass() instead of calling loadClass(), the ClassLoader won't check its parent loader for ClassLoaderLocals.
> 
> Finally, paper over this with a nice, ThreadLocal-like API that hides the ugly reflection.
> 
> Bob
> 
> On Thu, Sep 16, 2010 at 7:56 AM, Jevgeni Kabanov <ekabanov at gmail.com> wrote:
> Hi guys,
> 
> I'd like to contribute two new classes to the JDK7 and add a new package-visible field to the ClassLoader. These classes would be meant for the framework and server developers to allow for greater control over the references between classes in different class loaders. Specifically the goal would be to prevent the notoriously common classloader leaks. The motivation is partially described here:
> http://dow.ngra.de/2009/06/15/classloaderlocal-how-to-avoid-classloader-leaks-on-application-redeploy/
> That blog post also describes a way to backport it to older Java versions, unfortunately we found that the described approach will not work in some esoteric cases.
> 
> The pseudo-code follows. It's not really optimized or even tested and is only meant to illustrate the functionality and complexity of the proposal. I'd like to hear your feedback on this.
> 
> class ClassLoader {
>   Map localMap = new HashMap();
>   //...
> }
> 
> public class ClassLoaderLocal {
>   private Object key = new Object();
>  
>   public Object get(ClassLoader cl) {
>     cl.localMap.get(key);
>   }
>  
>   public void set(ClassLoader cl, Object value) {
>     cl.localMap.put(key, value);
>   }
> }
> 
> public class ClassLoaderWeakReference extends Reference {
>   private final WeakReference clRef;
>   private final ClassLoaderLocal cll = new ClassLoaderLocal();
>   public ClassLoaderWeakReference(Object target) {
>      clRef = new WeakReference(target.getClass().getClassLoader());
>      cll.set(target.getClass().getClassLoader(), target);
>   }
>   
>   public Object get() {
>     if (clRef.get() == null) 
>       return null;
>     return cll.get((ClassLoader) clRef.get());
>   }
> }
> 
> Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
> jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
> "jrebel is r0x: http://bit.ly/6fRGji" - mschambeck
> 
> 


Jevgeni Kabanov: Founder & CTO at ZeroTurnaround
jevgeni at zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
"Planning to give #JRebel 3.0 a try. No more Java restarting." - Jan Van Hoecke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100916/0e3a8518/attachment.html>