[
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)
