harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "weldon washburn (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-4195) [drlvm][threading] design/development issues which block other bugs
Date Sat, 16 Jun 2007 22:59:26 GMT
[drlvm][threading] design/development issues which block other bugs

                 Key: HARMONY-4195
                 URL: https://issues.apache.org/jira/browse/HARMONY-4195
             Project: Harmony
          Issue Type: Improvement
            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

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

View raw message