You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Pavel Rebriy (JIRA)" <ji...@apache.org> on 2008/01/16 15:12:38 UTC
[jira] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559502#action_12559502 ]
Pavel Rebriy commented on HARMONY-3289:
---------------------------------------
After committing HARMONY-5352 the issue is out-of-date and could be closed.
> [drlvm][thread] Explicit memory model for thread blocks
> -------------------------------------------------------
>
> Key: HARMONY-3289
> URL: https://issues.apache.org/jira/browse/HARMONY-3289
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Salikh Zakirov
> Assignee: 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, thread_block_memory_model.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.