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] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory model for thread blocks
Date Tue, 20 Mar 2007 19:30:32 GMT

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

Salikh Zakirov commented on HARMONY-3289:

The attached files
* 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
contain a snapshot of my development on this issue.

The current status is as follows:
* some cunit tests fail, one of the known failures is caused by breaking the system-wide assumption
about circular locking of HyThread, j.l.Thread and JVMTIThread structures. (HyThread does
not exist, and the test fails with assertion when trying to get to JVMTIThread from j.l.Thread
through non-existent NULL HyThread). Needs fixing the linking model of JVMTIThread.

* kernel test ThreadTest.testInterrupt_NEW, testInterrupt_TERMINATED, interruption status
is not preserved when interrupting not yet started or already terminated thread. This happens
because interruption status is only propagated to native thread block when it exists, and
is dropped if there is no thread block. 

* the problem of hythread_join() is open: I wasn't able to come up with feasible correct algorithm
of joining a thread using a thread block pointer as an argument. The attached patches contain
an attempt at making it, but it still has a race condition, so it was a failed attempt. The
possible solution would be to remove hythread_join() interface completely, and rewrite the
only non-trivial user -- shutting down daemon threads -- with a different approach.

> [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,
> Attached is a patch for discussing a major architecture change in thread management in
> 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.

View raw message