Stefan Egli created FELIX-4462:
----------------------------------
Summary: Classloader deadlock in Java6 between two bundles
Key: FELIX-4462
URL: https://issues.apache.org/jira/browse/FELIX-4462
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE
Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit
Server VM (build 20.65-b04-462, mixed mode)
Reporter: Stefan Egli
As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug
4670071 [2] is not fixed). The problem is the hidden, implicit
ClassLoader.loadClassInternal which is is synchronized(this) in that case.
Consider the following scenario:
* bundle 2 wants to load a class of bundle 1 - hence is not synchronized with
bundle 1's classloader - thus uses the m_classLocks locking mechanism to lock
bundle 1's classloader for the particular class being loaded. Then calls
defineClass (with bundle 1's classloader)
* before it can do so, bundle 1 wants to load the same class (of bundle 1) -
hence does a synchronized loadClassInternal. then reaches the m_classLocks
locking mechanism and notices that there's another thread loading the class
-> this results in the deadlock reported.
There's multiple fixes for this:
* use Java 7
* use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
* create a special Java 6 classloader (Java 7 would use the current one) which
does a plain synchronized findClass() - and replaces all
synchronized(m_classLocks) with synchronized(this)
[0] http://markmail.org/thread/crwqzqobxgob7q3n
[1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071
--
This message was sent by Atlassian JIRA
(v6.2#6252)
