On 09:45 Mon 18 Apr , Andrew Haley wrote:
> 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.
>
Be correct first. Only then worry about performance.
> > OTOH, if URLClassLoader is doing the same, we are not impacting the
> > performance any further so it'd be okay.
>
> 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;
> }
>
That change is due to:
4735126: (cl) ClassLoader.loadClass locks all instances in chain when delegating
Summary: Added support for parallel-capable class loaders
Reviewed-by: alanb
> Andrew.
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37