harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
Date Sun, 12 Aug 2007 12:03:43 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Xiao-Feng Li closed HARMONY-4601.

    Resolution: Fixed
      Assignee: Xiao-Feng Li

Fixed with a workaround in GC that yields the thread who can't hold the spin lock.

(Reason why it's a workaround was explained in dev mailing list:

Mutex can be used here, but I don't know if it's correct fix of the issue. Basically the list
of mutators is maintained and used by GC in following ways:
1) insert/remove a mutator from the list during thread creation/termination (or attach/detach);
2) iterate the list for mutator-local data during garbage collection;

For 1) above, the assumption is, thread creation/termination process is serialized (Assumption
1), so we don't really need any lock protection for the list insertion/removal.

For 2) above, the assumption is no new mutators will be created/terminated during the STW
collection (Assumption 2),  the list iteration doesn't need lock protection either;

But we actually found neither Assumption 1 nor 2 was guaranteed to be hold true, so we introduced
spinlock for temporary solution, hoping to remove spinlock for the list access finally.

Assumption 2 is a little more subtler than it looks. It's easy to understand that, during
STW collection, there is no thread is created. But there is a special case when a thread is
in the middle of its
creation process. If the creation action is not atomic wrt STW collection, it is possible
for a thread creation to be initiated before STW and finished during STW, which means, this
mutator is inserted into the list during the STW collection.

To summarize the two assumptions, GC expects the thread creation/termination be atomic wrt
each other and wrt the collection process. In that case, the locks, no matter spin-yield or
mutex can be removed. )

> [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
> ----------------------------------------------------------------------------------
>                 Key: HARMONY-4601
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4601
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux/ia32
>            Reporter: Gregory Shimansky
>            Assignee: Xiao-Feng Li
> The test creates a big number of threads (4000) that mostly do nothing. Threads are waiting
and then are joined by the main thread. This mostly doesn't consume CPU on the machine. But
then all of these threads go through gc_thread_kill function. It executes thread deletion
from a list under a global spin-lock, so all 4000 threads are waiting on it using CPU at the
same time since the lock spins inside of the loop.
> This test usually doesn't finish on linux/ia32 (for some reason it works on other platforms)
and times out. So I created this bug report to exclude it.

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

View raw message