harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4195) [drlvm][thread] design/development issues which block other bugs
Date Wed, 16 Jan 2008 14:22:34 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559508#action_12559508
] 

Pavel Rebriy commented on HARMONY-4195:
---------------------------------------

The issue seems to be out-of-date and could be closed.

> [drlvm][thread] design/development issues which block other bugs
> ----------------------------------------------------------------
>
>                 Key: HARMONY-4195
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4195
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>            Reporter: weldon washburn
>            Assignee: weldon washburn
>            Priority: Minor
>
> Below is the email which describes the needed DRLVM Thread Manager development.  The
concept is to set  the status bugs that need to wait for this cleanup to "depends on" the
JIRA you are looking at.
> From: Weldon Washburn <weldonwjw@gmail.com> 
> To: dev@harmony.apache.org
> Date: Mon, Apr 2, 2007 at 2:51 PM
> All,
>  
> Below is a rough list of DRLVM threading design problems that affect stability.  In an
email titled, "[general] What platforms do we support?", Tim Ellison suggests putting together
a list of stuff that needs to happen for "M xx" release.  Below are the threading issues that
need to be factored in. 
>  
> Most likely only a small part of the below is likely to happen if M1 ships at the end
of April.  I have not yet had the time to categorize the below into a roadmap time line. 
I will take a stab at a Thread Manager timeline soon. 
>  
> Thread Block Lifecycle  (quoted from harmony-3288) 
> Each thread has a memory structure (so called "thread block", struct HyThread), which
is associated with the thread using thread-local storage. The vast majority 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. 
>  
> Part of Java Thread State is Stored in Java Object, Part in Native C struct 
> This leads to race conditions and stale data.  The current leading contender is to store
all thread state in the C struct and use native methods to access from java code. 
> Varying Mutexes Protect Different Parts of Thread State, Each Thread Has Its Own Mutex

> The goal at this point in time is to make the synchronization as simple and deadlock-free
as possible.  The maximum rate of threading APIs such as java.lang.Thread.sleep(), interrupt(),
start(), exit is a secondary consideration. 
> java.lang.Thread.join() bugs should also be fixed while designing/implementing the above.

> Remove Remaining Thread Manager Calls to APR 
> Example why this is needed - APR memory allocator doesn't really have a deallocator.
 This means cycling threads causes memory leaks. 
> Race Conditions in Lock Reservation 
> The first thing is to confirm that there are problems in this subsystem.  :Lock Reservation
is a complex threading issue mainly because the system needs to be able to steal a lock reservation
from an active thread that currently does not hold the desired lock.  This requires careful
synchronization between the requestor and target threads. 
> The Interface Requirements Between Threading Manager and JVMTI Are Not Well Understood
And Could Impact Threading Module Design 
> This requires a design discussion between threading and jvmti engineers.  The goal is
to support as much of the JVMTI interface as possible with as little disruption as possible
to the Thread Manager. 
> Resolve the problem of two threading libraries co-exisiting:  IBM PORTLIB and DRLVM Thread
Manager.  This is a problem because the same functionality is provided by two libraries. 
At the very least this leads to substantial confusion during debug.  And is often suspected
in deadlocks and race conditions. 
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message