felix-dev mailing list archives

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

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

Mime
View raw message