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

[Jared Burns <jared-eclipse@xxxxxxxxx>]

I don't think we should update the details pane when stepping. It is way too 
expensive.

I suggest that we either require the user to reselect a variable to recompute 
the detail or we could update it automatically, but only after a period of 
time has passed since the last step.

- Jared

On Thursday 01 August 2002 09:24 am, you wrote:
> 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