ClassLoader Deadlock fix was: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
glyn_normington at UK.IBM.COM
Wed May 30 04:27:51 PDT 2007
Adrian <abrock at REDHAT.COM> wrote on 25/05/2007 12:44:54:
> On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote:
> > A better approach would be for the Java 7 platform to provide first
> > class support for JSR 291. This boils down to standardising the
> > experimental class loader deadlock fix ()
> Fixing the deadlock just moves the problem.
> You'll still get ClassCircularityErrors when competing threads
> try to load classes using locks other than the classloader
> synchronization or they don't synchronize on the loadClass()
> or they release the lock during the classloading request
> to let others have a go (again to avoid the deadlock).
> This is because of the way the dictionary class determines
> whether a circular load is occuring.
> Although I haven't tried it with OpenJDK so maybe the
> dictionary class contains some other fixes to workaround the
> The simple form of the problem:
> has been fixed in recent JDKs, but spurious CCEs
> still exist in other cases.
> e.g. the testAbstractFactoryConcurrent() here:
> will show CCEs in the log if you enable TRACE logging.
> 1445 TRACE [ClassLoaderManager] Run failed with exception
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
Some spurious CCEs were indeed fixed before the experimental deadlock fix
was introduced, but there may be more to do to make this fix robust and
complete. If you raise a sunbug for the above testcase, best to report it
here so that class loader rearchitecture folks can take it into
consideration for Java 7.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr277-eg-observer