harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (HARMONY-1559) [drlvm][jvmti] Processing breakpoints works incorrectly in multi-thread mode.
Date Tue, 26 Sep 2006 13:56:51 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-1559?page=all ]

Geir Magnusson Jr reassigned HARMONY-1559:

    Assignee: Geir Magnusson Jr

> [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
>         Assigned To: Geir Magnusson Jr
>         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
> 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
>    - 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
> - Renamed several methods and extended search capabilities in both VMBreakPoints and
> - 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


View raw message