[FELIX-4462] Classloader deadlock in Java6 between two bundles

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: framework-4.2.1
• Fix Version/s: framework-4.4.0
• Component/s: Framework
• 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)
• Assignee: Richard S. Hall
• Reporter: Stefan Egli
• Created: 19/Mar/14 14:36
• Updated: 19/Mar/14 16:23
• Resolved: 19/Mar/14 16:23

Description

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

Issue Links

• is related to: FELIX-3953 Deadlock in classloaders
• is related to: FELIX-3553 Use of parallel class loading capability of JDK7