harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory model for thread blocks
Date Sat, 03 Mar 2007 10:52:51 GMT

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

Gregory Shimansky commented on HARMONY-3289:

I wonder about JVMTI threading functionality. It is a native code and has no access to the
java space lock object. How shall JVMTI functions lock the state of a thread?

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