harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [drlvm][threading] a list of design/development issues that need coordination with the [general] "M1" map
Date Mon, 02 Apr 2007 21:51:30 GMT

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

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

   - 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<https://issues.apache.org/jira/browse/HARMONY-2742>for
more details.
   - Part of Java Thread State is Stored in Java Object, Part in Native C
      - 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.

   Weldon Washburn
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message