Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <22640852.1172853650892.JavaMail.jira@brutus>
Date: Fri, 2 Mar 2007 08:40:50 -0800 (PST)
From: "Salikh Zakirov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-3288) [drlvm][thread] Use Pthreads/Win32
 rather than APR for mutexes and condition variables
In-Reply-To: <32670616.1172852751044.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Salikh Zakirov updated HARMONY-3288:
------------------------------------

    Component/s: DRLVM

> [drlvm][thread] Use Pthreads/Win32 rather than APR for mutexes and condition variables
> --------------------------------------------------------------------------------------
>
>                 Key: HARMONY-3288
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3288
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>            Reporter: Salikh Zakirov
>         Assigned To: weldon washburn
>         Attachments: 0001-allocate-fat-monitors-from-heap-directly-not-in-a-thread-pool.patch, 0002-rewritten-HyCond-and-HyMutex-to-use-pthread-calls.patch, 0003-fixed-callers-of-hymutex-and-hycond-to-use-address.patch
>
>
> Currently DRLVM uses APR mutexes and condition variables. These require APR memory pools to be allocated from,
> and releasing memory pools may be tricky at times. For example, the memory lifecycle of the native monitor is associated
> with the java object lifecycle, thus requires a specific object-specific pool. While this solution is possible, it will incur
> significant memory overhead.
> The attached patch series proposes a simplified model by using Pthreads or Win32 interfaces directly, without layering APR.
> It allows for explicit memory allocation and deallocation, and makes fixing thread memory model much easier.
> The patch series is incomplete, as it still uses APR thread creation APIs, and thus APR pools are still created for every thread.
> I will work further to remove this dependency as well.
> The patches

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