[jira] Commented: (HARMONY-4195) [drlvm][thread] design/development issues which block other bugs

["Pavel Rebriy (JIRA)" <ji...@apache.org>]

    [ 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 <we...@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.