felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
Date Wed, 19 Mar 2014 15:23:49 GMT

     [ 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

View raw message