Mailing-List: contact harmony-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Message-ID: <4747035.1159021703472.JavaMail.jira@brutus>
Date: Sat, 23 Sep 2006 07:28:23 -0700 (PDT)
From: "Pavel Rebriy (JIRA)" <jira@apache.org>
To: harmony-commits@incubator.apache.org
Subject: [jira] Updated: (HARMONY-1559) [drlvm][jvmti] Processing
 breakpoints works incorrectly in multi-thread mode.
In-Reply-To: <11381549.1159021702371.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/HARMONY-1559?page=all ]

Pavel Rebriy updated HARMONY-1559:
----------------------------------

    Attachment: Multi-threaded-breakpoints.patch

This patch depends on H-1555

> [drlvm][jvmti] Processing breakpoints works incorrectly in multi-thread mode.
> -----------------------------------------------------------------------------
>
>                 Key: HARMONY-1559
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1559
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Pavel Rebriy
>         Attachments: Multi-threaded-breakpoints.patch
>
>
> In the current implementation of breakpoints processing loop through breakpoints is performed under breakpoints lock. Before reporting breakpoint thread raises the breakpoint flag that it was processed, and no need to report it again. But then the thread calls breakpoint event callback function it releases the lock, and get it after callback. It works fine in case of one thread. In multi-thread mode, another thread which catches the same breakpoint processing it while the first thread is in event callback. But breakpoint has the processed flag on and the second thread doesnt report it. It clears breakpoint processed flag and leaves breakpoint handler. The first thread returns from event callback and finds non-processed breakpoint and report the same breakpoint again. If the number of threads is increased we could get unpredictable behaviour.
> The problem is the only flag in breakpoint descriptor is not enough in multi-thread mode to determine if breakpoint was already processed by all threads. The solution for this problem is to change breakpoints processing model.
> The following patch fixes the described problem and, also, fixed numerous issues discovered while progressing with implementation of this new model. The following issues are fixed in this patch:
> - Added logic for correct processing of breakpoints and JVMTI environments in multi-threaded execution.
>    - Reverted order of adding breakpoints and interfaces (was stack  became queue). This change is required in new processing algorithm to ensure breakpoints and interfaces are inserted to the end of respective collections.
>    - Removed is_processed flag from breakpoint structure.
>    - Removed locking interface from VMBreakInterface. Localized locking in VMBreakPoints  methods.
> - Renamed several methods and extended search capabilities in both VMBreakPoints and VMBreakInterface.
> - Moved is_interp flag and logic from breakpoint to VMBreakInterface class.
> - Moved JVMTI environment associated logic from breakpoint associated data to VMBreakInterface.
> - Added returning result of processing breakpoint under interpreter.
> - Fixed and improved debug tracing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira