[jira] [Commented] (GROOVY-8067) Possible deadlock when creating new ClassInfo entries in the cache

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jira] [Commented] (GROOVY-8067) Possible deadlock when creating new ClassInfo entries in the cache

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/GROOVY-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16088680#comment-16088680 ]

John Wagenleitner commented on GROOVY-8067:
-------------------------------------------

It looks like the issue might be related to the {{ManagedLinkedList}} (MLL) iterator vs the {{ManagedConcurrentLinkedQueue}} (MCLQ) iterator.  The MLL {{iterator#remove}} method seems to not correctly relink the list (head, tail).

{code}
import org.codehaus.groovy.util.*

mml = new ManagedLinkedList<String>(ReferenceBundle.getHardBundle())
//mml = new ManagedConcurrentLinkedQueue<String>(ReferenceBundle.getHardBundle())
mml.add('foo')
mml.add('bar')
mml.add('baz')

for (Iterator<String> itr = mml.iterator(); itr.hasNext(); ) {
    String s = itr.next()
    println s
    itr.remove()
}
{code}

Output from MLL:

{code}
foo
{code}

Output from MCLQ:

{code}
foo
bar
baz
{code}

So with the old code using MLL any calls to {{clearModifiedExpandos}} would always only remove the first one.

The [call to ExpandoMetaClass.enableGlobally in the grails-melody-plugin|https://github.com/javamelody/grails-melody-plugin/blob/4da5c1e7092f7841e6133fd790baa0419340a6ad/src/main/groovy/grails/melody/plugin/MelodyInterceptorEnhancer.groovy#L32] triggers a call to {{clearModifiedExpandos}}.  By this time Grails core has already added the {{encode}} methods.  The old code just by luck would not remove the modified expandos (and more importantly is the call to {{setStrongMetaClass(null)}}) but the new MCLQ really does clear all modified expandos.

Assuming that's the problem, not sure what's the appropriate fix.  It seems to me like the old MLL is broken, it doesn't look like this would have been the intended behavior.  So guess the question would be whether the responsibility lies with the caller of {{ExpandoMetaClass#enableGlobally}} to check first to see if already enabled or whether that method should not clear if already enabled.

> Possible deadlock when creating new ClassInfo entries in the cache
> ------------------------------------------------------------------
>
>                 Key: GROOVY-8067
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8067
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-runtime
>    Affects Versions: 2.4.8
>            Reporter: John Wagenleitner
>            Assignee: John Wagenleitner
>            Priority: Critical
>             Fix For: 2.4.9
>
>         Attachments: ClassInfoDeadlockTest.java
>
>
> When running Groovy without {{-Dgroovy.use.classvalue=true}} the ClassInfo instances are cached in a {{ManagedConcurrentMap}} (MCM).  New values are computed on demand and computation involves both a lock on a segment within the MCM and a lock on the {{GlobalClassSet}} (GCS) which is backed by a {{ManagedLinkedList}}.  The problem is that both the ManagedConcurrentMap and the GlobalClassSet share the same ReferenceQueue.
> Assume there is an enqueued {{ClassInfo}} value that is stored in Segment2 of the MCM.  Now assume that Thread1 and Thread2 both request {{ClassInfo.getClassInfo(..)}} for two different classes that do not currently exist in the cache.  Assume that based on hashing Thread1 gets a lock on Segment1 and Thread2 gets a lock on Segment2.  Assume that Thread1 is the first to call computeValue which in turn calls {{GlobalClassSet.add(..)}}.  This call adds a new value to a {{ManagedLinkedList}}, and since it's managed the add operation will process the ReferenceQueue. So Thread1 will attempt to dequeue the ClassInfo and the finalizeReference method on it's entry will attempt to remove it from Segment2. Thread2 holds the lock for Segment2 and Thread2 is blocked and can't progress it's waiting on the the lock Thread1 holds the lock for the GlobalClassSet, so deadlock occurs.
> The attached test case includes a thread dump at the bottom.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Loading...