[jira] [Updated] (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 updated FELIX-4462: --- Fix Version/s: framework-4.4.0 > 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)
[jira] [Updated] (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 updated FELIX-4462: --- Attachment: FELIX-4462.txt I've attached a patch that tries to determine if we are using a parallel class loader or not. If so, it uses the class locks list as the lock object, if not, it uses the class loader itself as the lock object. Please test this patch and see if it works. Thanks. > 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 > Attachments: FELIX-4462.txt, 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] [Updated] (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 updated FELIX-4462: --- Attachment: classLockMonitor.FELIX-4462.patch2 Attached a patch which replaces the synchronization monitor of m_classLocks to this. With this fix the Java6DeadlockTest succeeds. > 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 > 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] [Updated] (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 updated FELIX-4462: --- Attachment: suggested.synchronized.FELIX-4462.patch Attached the synchronized findClass as mentioned in the description of this ticket. This would fix the deadlock encountered - but prevents parallel classloading for Java 7 onwards. So maybe there's a better solution... > 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 > Attachments: 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] [Updated] (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 updated FELIX-4462: --- Attachment: test.reproducingFELIX-4462.patch Adding a patch which contains a test (Java6DeadlockTest) that reproduces the deadlock. I had a problem reproducing it via maven (mvn clean test), there is succeeds, but when running it in Eclipse it indeed reproduces the deadlock. When running it in Eclipse with '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' it succeeds. > 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 > Attachments: 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)
