[jira] Closed: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow

["Xiao-Feng Li (JIRA)" <ji...@apache.org>]

     [ 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.