harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-1519) [DRLVM] Performance degradation while working in Eclipse
Date Thu, 21 Sep 2006 10:20:24 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1519?page=comments#action_12436490 ] 
            
Alexey Varlamov commented on HARMONY-1519:
------------------------------------------

I found endless loops sporadically occur in the patched APR function _thread_cond_timedwait().


Typical backtrace is:
--------------------------------------------------------------------------------
  ntdll.dll!7c82ed54()  
  ntdll.dll!7c822124()  
  kernel32.dll!77e6baa8()  
  ntdll.dll!7c82f9dd()  
  kernel32.dll!77e6ba12()  
> hythr.dll!_thread_cond_timedwait(apr_thread_cond_t * cond=0x00828140, apr_thread_mutex_t
* mutex=0x00828108, unsigned long timeout_ms=0xffffffff)  Line 63 + 0x11 C
  hythr.dll!apr_thread_cond_wait(apr_thread_cond_t * cond=0x00828140, apr_thread_mutex_t *
mutex=0x00828108)  Line 105 + 0xf C
  hythr.dll!condvar_wait_impl(HyCond * cond=0x00828140, HyMutex * mutex=0x00828108, __int64
ms=0x0000000000000000, int nano=0x00000000, int interruptable=0x00000000)  Line 70 + 0x25
C
  hythr.dll!sem_wait_impl(HySemaphore * sem=0x008280f0, __int64 ms=0x0000000000000000, int
nano=0x00000000, int interruptable=0x00000000)  Line 68 + 0x19 C
  hythr.dll!hysem_wait(HySemaphore * sem=0x008280f0)  Line 106 + 0x12 C
  gc.dll!gc_thread_func(void * arg=0x0536ec60)  Line 209 C++
  hythr.dll!thread_start_proc(apr_thread_t * thd=0x0082bea8, void * p_args=0x0082be10)  Line
707 C
  hythr.dll!dummy_worker(void * opaque=0x0082bea8)  Line 80 C
  hythr.dll!_threadstartex(void * ptd=0x003a1f28)  Line 241 + 0x6 C
  kernel32.dll!77e66063()  
--------------------------------------------------------------------------------

For the selected frame, locals are:
--------------------------------------------------------------------------------
- cond 0x00828140 {...} apr_thread_cond_t *
+ pool 0x00827dc8 {...} apr_pool_t *
 event 0x00000734 void *
 signal_all 0x00000000 int
 num_waiting 0x00000001 int
 signalled 0x00000001 int
 wait_level 0x0000001b unsigned int
 notify_level 0x0000001a unsigned int
 cond->event 0x00000734 void *
+ mutex 0x00828108 {...} apr_thread_mutex_t *
 res 0x00000000 unsigned long
 timeout_ms 0xffffffff unsigned long
--------------------------------------------------------------------------------

The code of the loop is:
--------------------------------------------------------------------------------
while (1) {
    cond->num_waiting++;
    apr_thread_mutex_unlock(mutex);
    res = WaitForSingleObject(cond->event, timeout_ms);
    apr_thread_mutex_lock(mutex);
    cond->num_waiting--;

    if (res != WAIT_OBJECT_0) {
        apr_status_t rv = apr_get_os_error();
        if (res == WAIT_TIMEOUT) {
            return APR_TIMEUP;
        }

        return apr_get_os_error();
    }

    if (cond->signal_all) {
                [snip]
    }
    else if (cond->signalled && NOT_STALED(this_wait_level, cond->notify_level))
{
        cond->signalled = 0;
        ResetEvent(cond->event);
        break;
    }
}
--------------------------------------------------------------------------------

Interpretation is the following:
Somehow the thread condition become STALE (i.e. wait_level  > notify_level ), and after
the event is signalled, there is no way out of the loop but the event is not reset. So it
just wastes CPU cycles calling WaitForSingleObject on signalled event.

> [DRLVM] Performance degradation while working in Eclipse
> --------------------------------------------------------
>
>                 Key: HARMONY-1519
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1519
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: 2xXeon CPU, Windows 2003 Server SP1
>            Reporter: Alexey Varlamov
>            Priority: Critical
>
> The DRLVM sometimes become VERY slow during Eclipse session, it almost freezes whole
system consuming 99% CPU.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message