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] Created: (HARMONY-3289) [drlvm][thread] Explicit memory model for thread blocks
Date Fri, 02 Mar 2007 16:55:50 GMT
[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

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