You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Salikh Zakirov (JIRA)" <ji...@apache.org> on 2007/03/02 17:55:50 UTC
[jira] Created: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
[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 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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Salikh Zakirov updated HARMONY-3289:
------------------------------------
Attachment: 0002-WIP-explicit-thread-block-lifecycle.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.
[jira] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ 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, 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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Rebriy updated HARMONY-3289:
----------------------------------
Attachment: thread_block_memory_model.patch
The updated 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, 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.
[jira] Closed: (HARMONY-3289) [drlvm][thread] Explicit memory model
for thread blocks
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky closed HARMONY-3289.
--------------------------------------
Resolution: Fixed
Assignee: Gregory Shimansky (was: weldon washburn)
Closing as fixed since all of bug's parts were integrated.
> [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: Gregory Shimansky
> 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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Salikh Zakirov updated HARMONY-3289:
------------------------------------
Attachment: (was: explicit-thread-block-lifecycle.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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Salikh Zakirov updated HARMONY-3289:
------------------------------------
Attachment: explicit-thread-block-lifecycle.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
> Attachments: explicit-thread-block-lifecycle.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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Salikh Zakirov updated HARMONY-3289:
------------------------------------
Attachment: 0003-hythread_join-reflect-contract-change-in-thread-c-unit-tests.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.
[jira] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ 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 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.
[jira] Updated: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li updated HARMONY-3289:
----------------------------------
Issue Type: Bug (was: Wish)
> [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.
[jira] Assigned: (HARMONY-3289) [drlvm][thread] Explicit memory
model for thread blocks
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weldon washburn reassigned HARMONY-3289:
----------------------------------------
Assignee: weldon washburn
> [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 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.