groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8067) Possible deadlock when creating new ClassInfo entries in the cache
Date Wed, 12 Jul 2017 21:56:00 GMT


Paul King commented on GROOVY-8067:

Git bisect points to the respective commit for this issue for the below Grails plugin issue:

I haven't fully investigated and don't have a standalone reproducer yet. I'll raise a separate
issue when I find something conclusive.

> Possible deadlock when creating new ClassInfo entries in the cache
> ------------------------------------------------------------------
>                 Key: GROOVY-8067
>                 URL:
>             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:
> 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

View raw message