[RFC]: Linkage Error fix.

[Denis Lila]

I guess I should have read this before I responded to Deepak.

> This is exactly how ClassLoader does it in 1.7. However,
> ClassLoader's code is a bit more clear:
> 
> protected Class<?> loadClass(String name, boolean resolve)
> throws ClassNotFoundException
> {
> synchronized (getClassLoadingLock(name)) {
> 
> where
> 
> protected Object getClassLoadingLock(String className) {
> Object lock = this;
> if (parallelLockMap != null) {
> Object newLock = new Object();
> lock = parallelLockMap.putIfAbsent(className, newLock);
> if (lock == null) {
> lock = newLock;
> }
> }
> return lock;
> }

Interesting. That's almost exactly the same as my solution
(although, I don't know if it's clearer ;-).

In my e-mail with the patch I expressed some concern over
the CHM getting too large after a while, and as a fix I
proposed having one lock per class_name.hashCode() % small_prime_number
instead of one lock for every class name. What do you
think about this?

Regards,
Denis.

----- Original Message -----
> On 15/04/11 20:55, Deepak Bhole wrote:
> 
> > Did you look into how URLCloassLoader and others mitigate the
> > problem?
> > If I am not mistaken, all class load requests go through
> > JNLPClassLoader,
> > and synchronizing on each such call can get expensive.
> 
> In 1.6 ClassLoader.loadClass() is a synchronized method anyway.
> 
> There's something of a myth about the expense of synchronization that
> isn't usually justified by actual measurements. It's usually only a
> compareAndSwap, and there is little pain for uncontended cases.
> Avoiding synchronization with more complex schemes may actually be
> slower; you have to measure it.
> 
> > OTOH, if URLClassLoader is doing the same, we are not impacting the
> > performance any further so it'd be okay.
> 

> 
> Andrew.