Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <29566610.1172855390929.JavaMail.jira@brutus>
Date: Fri, 2 Mar 2007 09:09:50 -0800 (PST)
From: "weldon washburn (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Assigned: (HARMONY-3289) [drlvm][thread] Explicit memory
 model for thread blocks
In-Reply-To: <17712791.1172854550882.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

weldon washburn reassigned HARMONY-3289:
----------------------------------------

    Assignee: weldon washburn

> [drlvm][thread] Explicit memory model for thread blocks
> -------------------------------------------------------
>
>                 Key: HARMONY-3289
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3289
>             Project: Harmony
>          Issue Type: Wish
>          Components: DRLVM
>            Reporter: Salikh Zakirov
>         Assigned To: weldon washburn
>         Attachments: explicit-thread-block-lifecycle.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.