[jira] [Closed] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli closed FELIX-4462. -- Thanks! Test works fine with the fix now. 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 Assignee: Richard S. Hall Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch 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)
[jira] [Closed] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-4462. -- Resolution: Fixed 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 Assignee: Richard S. Hall Fix For: framework-4.4.0 Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch 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)
