harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Salikh Zakirov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory model for thread blocks
Date Tue, 20 Mar 2007 19:24:32 GMT

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

Salikh Zakirov updated HARMONY-3289:
------------------------------------

    Attachment: 0001-jthread_join-is-not-used-anywhere-removed.patch

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


Mime
View raw message