ClassLoader Deadlock fix
Stanley M. Ho
Stanley.Ho at SUN.COM
Wed May 30 11:40:57 PDT 2007
Hi JSR 277 experts,
Below are some comments from Jeff Nisewanger and Karen Kinnear who are
working on the ClassLoader API improvements for Java SE 7. If you are
interested in contributing to the ClassLoader API improvements as a
reviewer, you may contact Jeff and Karen at jeff.nisewanger at sun.com and
karen.kinnear at sun.com.
-------- Original Message --------
Sun is working on the ClassLoader Deadlock fix. Our goal is to work
closely with the community, of which the 277 EG contains key members, in
coming up with small modifications to the current ClassLoader APIs to
resolve that issue.
As we've mentioned before, and Glyn even points out in his referenced
blog, we did add a temporary risky unstable workaround which only really
handles a small special case for WebSphere 6.1 which should be
supplanted by the new mechanism as that becomes available.
One of the key issues here is that a prerequisite for avoiding the
ClassLoader deadlocks is that the JVM must not hold the ClassLoader
Object lock when it calls out to LoadClass[Internal]. And presumably the
lock must not be held when the custom class loader's loadClass() is called.
As anyone who has written a custom class loader would immediately
recognize, changing that underlying assumption is inherently risky. It
is all too easy to break existing custom class loaders that were perhaps
unknowingly relying on that lock to protect critical data and
operations. Those are the kind of breakages that are extremely timing
dependent and can pass many test cases and then unexpectedly fail in the
field. I'm sure you all also remember when Unix user level libraries
were converted to being MT-safe. We didn't get them all right the first
time around. We don't want to put our customers in that position.
So a part of the ClassLoader API modifications would be for class
loaders to explicitly declare that they are safe for parallel class
loading, both for multiple classes in the same class loader, and for
multiple instances of the same class in the same class loader.
I have been assuming that this would be the default for JSR 277, but we
can work that issue in detail when we have a strawman ClassLoader API
In the meantime, thank you very much to Adrian Brock for his
classcircularity example. I will be studying it in detail. If any other
EG member has a test scenario they would like to describe to us or even
better they have a test case for, we would very much appreciate it.
And if you are interested in contributing to the ClassLoader API
improvements as a reviewer, please let us know.
Jeff Nisewanger & Karen Kinnear
More information about the jsr277-eg-observer