[RFC]: Linkage Error fix.

[Deepak Bhole]

* Andrew Haley <aph at redhat.com> [2011-04-18 14:01]:
> On 04/18/2011 06:48 PM, Deepak Bhole wrote:
> > * Dr Andrew John Hughes <ahughes at redhat.com> [2011-04-18 13:10]:
> >> 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.
> > 
> > Replying here for this message:
> > 
> > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html
> > 
> > The new patch synchronizes all of loadClass. I am against this
> > approach with the current design. 
> > 
> > The latter part of loadClass() connects to remote sites to download
> > additional jars. Networks are unreliable and synchronizing a critical
> > method like loadClass knowing it can get delayed on network is a bad
> > idea IMO.
> > 
> > That is one of the reasons I suggested studying how URLClassLoader does
> > it.. it too has to deal with remote connectivity for loading, so it
> > probably has a cleaner solution for this.
> 
> You can call getResource, which doesn't need locking, and then call
> defineClass(name, resource) only once you have the bytes.
> 

Just finished studying URLClassLoader. Interestingly enough, it
ultimately blocks class loading on network access too.

ClassLoader.loadClass() is synchronized. If a class is not loaded, it
calls findClass() which is overloaded by URLClassLoader.
URLClassLoader.findClass() ultimately calls JarLoader.ensureOpen() if 
the class is not found. ensureOpen() opens a network connection
(confirmed by checking local server load) while in a synchronized block.

Making loadClass() will therefore be no worse than what URLClassLoader
does. I am therefore okay with the patch in:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html

The security rewrite will inevitably change JNLPClassLoader
significantly, and I will re-assess this then to see if we can do
something better.

Cheers,
Deepak