Re: [jdt-debug-dev] Debug Event Processing

["Darin Wright" <Darin_Wright@xxxxxxx>]

On further investigation/experimentation, I have found there are more issues with event dispatch/toString evaluation/and rapid stepping.

* Although the evaluation engine provides serial execution of evaluations, the implementation of IJavaThread disallows overlapping evaluations - a second evaluation can be scheduled until the first completes. Thus, if two views are displaying details (_expression_ view and variables view), one of the views often shows the error message "toString failed - evaluation already in progress".
* I created a simple implementation (described in a previous post), that allowed the debug plug-in to run "runnables" after event dispatch is complete. Even when "toString()" evaluations are run after event dispatch, there can be conflicts with "step requests". That is when the user holds down the "step key", a toString() evaluation can begin (which is asynchronous), and then a step can (attempt) to start, which fails and displays an error message in the variables view - "Thread not suspended". This effectively causes a flash in the variables view, and collapses any expanded variables.

I beleive that the IJavaThread implementation needs to be reviewed for safety. Problems arise when there is more than one attempt to perform an operation on a thread (for example, a step and an evaluation). We need to implement a locking scheme that does not cause deadlocks/blocking operaitons. For example, I implemented a simple "counter" lock for the "step" and "evaluation" operations as an experiment. Each operation obtains the lock before proceeding, and releases the lock when done. On failure to obtain the lock, the operation aborts (and does not block). This solved the second problem stated above - i.e. an attempt to step while performing an evaluation simply aborts.

I have not found a solution to the first problem (allowing serial evaluations via the "runEvaluation" API).

Darin

"Darin Wright" <Darin_Wright@xxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 07/29/2002 01:58 PM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [jdt-debug-dev] Debug Event Processing

Further implementation details: 

* I believe this function should be placed in the debug core (rather than Java debug) 
* The debug core will have its own thread in which to execute runnables. In the Java debug case, events are fired from the JDI event dispatch thread. If one were to use the event firing thread to run a runnable, the debug model would no longer be able to process debug events, which could be undesirable, or even result in a deadlock. The "queued runnable thread" should be created when first required, and should automatically terminate when no debug sessions are active, or when the debug plug-in shuts down. 

Darin

Jared Burns <jared-eclipse@xxxxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 07/22/2002 05:14 PM Please respond to jdt-debug-dev

To:        jdt-debug-dev@xxxxxxxxxxx        cc:                Subject:        Re: [jdt-debug-dev] Debug Event Processing

Sounds good to me.

- Jared

On Monday 22 July 2002 05:01 pm, you wrote:
> Yes, that is the suggested implementation.
>
> Darin
>
>
>
>
>
> Jared Burns <jared-eclipse@xxxxxxxxx>
> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx
> 07/22/2002 04:41 PM
> Please respond to jdt-debug-dev
>
>
>         To:     jdt-debug-dev@xxxxxxxxxxx
>         cc:
>         Subject:        Re: [jdt-debug-dev] Debug Event Processing
>
> I want to make sure I understand the proposal. Is the following in-line
> with
> your description?
>
> 1. Create the method DebugPlugin#queueEventRunnable(Runnable). This method
>
> adds runnables to a collection.
> 2. Add code to the end of DebugPlugin#fireDebugEventSet(DebugEvent[])
> which
> spawns a thread to execute each runnable in the collection (I don't think
> we
> want to do this inline).
> 3. Interested DebugEventListeners, would add code to their
> handleDebugEvents(DebugEvent[]) methods like:
> DebugPlugin.queueRunnable(new Runnable() {
>   public void run() {
>     getDisplay.asynchExec(...);
>   }
> }
>
> Does that sound about right?
>
> - Jared
>
> On Monday 22 July 2002 04:06 pm, you wrote:
> > Following is a proposal for dealing with the toString() evaluation
>
> problem
>
> > described in a previous post.
> >
> > Summary of proposal: A debug event listener needs to be able to register
>
> a
>
> > Runnable, to be run after the current event dispatch is complete. This
> > allows an event listener to perform an evaluation (or some other
>
> response)
>
> > to a debug event, after event processing is complete.
> >
> > Consider the following scenario:
> >
> > * There are 3 debug event listeners - a debug view, a variables view,
>
> and
>
> > the _expression_ view
> > * A debug event is fired signalling that a step has completed
> >
> > The event processing currently goes like this (in the JDI event dispatch
> > thread)
> > * the debug view registers a runnable (A) with the Display queue to
> > refresh the suspended thread (re-draw stack frames)
> > * the variables view registers a runnable (B)  with the Display queue to
> > refresh and populate the details area
> > * the _expression_ view registers a runnable (C) with the Display queue to
> > refresh and populate the details area
> > * At some point the UI thread runs (A), and stack frames are re-drawn
> > * At some point the UI thread runs (B). Varialbes are updated, and then
>
> an
>
> > asynchronous evaluation (E1) is started in a seperate thread to compute
> > details for the selected variable
> > * At some point the UI thread runs (C). Expressions are updated, and an
> > asychronous evaluation (E2) is started in a sperate thread to compute
> > details for the selected _expression_
> >
> > The time at which E1 and E2 run, in relation to (C) is undetermined
> > currently. If E1 begins and then (C) attempts to access the thread which
> > is no longer suspended, a problem occurrs. We need to be able to run E1
> > and E2 serially after (C). The AST evalutaion engine implementation
> > guarentees evaluations are run serially (looking at the implementation),
> > so all we really need is to guarentee that E1 and E2 are run after (C).
> > This could be acheived by having a facility to execute a runnable after
> > the current event dispatch is complete (in the event dispatch thread).
> > Then E1 and E2 would work by submitting a Runnable to the new facility,
> > which would in turn submit runnables to the Display queue to perform E1
> > and E2. This would mean that E1 and E2 are queued up as UI runnables,
> > after (A,B,C). The evaluation engine provides serial execution of the
> > evaluations.
> >
> > Pros:
> > * Reasonably simple to implement
> >
> > Cons:
> > * Complex to explain (i.e. must understand debug events, UI (Display)
> > event queue, and evaluation interactions).
> >
> > Issues:
> > * Should the support to run a Runnable after the current event dispatch
>
> be
>
> > Debug platform support, or Java Debug specific support?
> >
> > Comments welcome.
> >
> > Darin
>
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev