[jira] Closed: (HARMONY-3289) [drlvm][thread] Explicit memory model for thread blocks

["Gregory Shimansky (JIRA)" <ji...@apache.org>]

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

Gregory Shimansky closed HARMONY-3289.
--------------------------------------

    Resolution: Fixed
      Assignee: Gregory Shimansky  (was: weldon washburn)

Closing as fixed since all of bug's parts were integrated.

> [drlvm][thread] Explicit memory model for thread blocks
> -------------------------------------------------------
>
>                 Key: HARMONY-3289
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3289
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Salikh Zakirov
>            Assignee: Gregory Shimansky
>         Attachments: 0001-jthread_join-is-not-used-anywhere-removed.patch, 0002-WIP-explicit-thread-block-lifecycle.patch, 0003-hythread_join-reflect-contract-change-in-thread-c-unit-tests.patch, thread_block_memory_model.patch
>
>
> Attached is a patch for discussing a major architecture change in thread management in DRLVM.
> Each thread has a memory structure (so called "thread block", struct HyThread), which is associated with the thread
> using thread-local storage. The vast majoring of threading functions expect a thread to have a valid thread block
> in order to operate correctly.
> The current thread block lifecycle is complex, as the thread block lifetime is associated with the corresponding java heap
> object lifetime. This requires a complex infrastructure for releasing thread blocks, using weak reference objects and reference
> queue in java heap. The complexity is fairly high, and for this reason the system was never implemented correctly, and currently
> DRLVM leaks memory on thread creation, see HARMONY-2742 for more details.
> The proposed change is to limit the lifetime of the thread block by the lifetime of the corresponding OS thread.
> Rationale: it makes the memory management much more straightforward, and also keeps the memory usage
> more predictable by avoiding dependency on weak reference/finalization infrastructure.
> However, the change has some drastic implications in the overall system design. Currently, there exist a number of interface
> functions, which receive the thread block pointer as an argument. These functions will become unsafe due to the fact
> that the thread block could be released asynchronously by other thread. The suggested solution for this issue is to
> bracket all such native function calls by following java code:
>   
>     synchronized (lock) {
>         if (!isAlive()) {
>               // use java.lang.Thread object fields to compute an answer
>          } else {
>               // use native interfaces to query or modify thread state
>               VMThreadManager.do_something(this, ...);
>         }
> And the thread is changing its "alive" state only in synchronized(lock) sections, thus ensuring that once we grab a thread lock
> and check that the thread is alive, we are guaranteed that the thread block will not be deallocated as long as we hold a thread lock.
> The way to ensure that the thread block does not vanish while we are working with it is grabbing a global thread lock, which is used
> to protect global thread list modification, and thus native thread creation and termination. Unfortunately, working with a global thread
> lock is subtle and is not possible in all places.
> Some of the native level functions which receive thread block pointer as an argument will become so unsafe that the easier way out
> will be to just remove them, for example, hythread_join().

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