harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5135) [drlvm]DRL VM hangs during stress.Mix running on x86-64
Date Mon, 19 Nov 2007 09:04:43 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543499
] 

Pavel Rebriy commented on HARMONY-5135:
---------------------------------------

Yes, I've replaced hycond_wait() function which contains safe point by hycond_wait_timed_raw()
which doesn't.
We cannot go to safe point while we are holding locktable_lock. We grab locktable_lock in
case of access or modification locktable. It is consider as an "atomic" operation, that why
there is no safe point during "atomic" access to locktable.

> [drlvm]DRL VM hangs during stress.Mix running on x86-64
> -------------------------------------------------------
>
>                 Key: HARMONY-5135
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5135
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux x86-64
>            Reporter: Pavel Afremov
>         Attachments: lock_table_fix.patch
>
>
> The safe_point called from hycond_wait, which called from many places include locktable_reader_enter
and locktable_writer_enter.
> From other side access to locatable there is in function hythread_reclaim_recources,
which works during stop the world. 
> It leads to dead lock, when first thread, which catch locktable monitor goes into safe
poin and GC starts. In this case GC can't complete work, because one or several threads waiting
on following stack, when first thread free locktable monitor:
> 	#1 <pthread_mutex_lock>
> 	#2 <hymutex_lock>
> #3<hythread_reclaim_resources>
> #4 <vm_reclaim_native_objs>
> #5 <gc_reclaim_heap>
> #6 <fspace_alloc>
> #7 ....
> So it's a deadlock when firs thread waits when second thread free monitor, and send thread
waits when first thread free the other monitor.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message