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

["Darin Wright" <Darin_Wright@xxxxxxx>]

True, we do not want to slow down rapid stepping by performing "toStrings()". In the current implementation, this happens by the luck of draw. When holding down the "step key", the step request almost always beats the next evaluation request (which results in a "toString() not available - thread not suspended" message in the details area). Only when the step key is released doe the evaluation occurr. Thus, in the current implementation, we rarley incurr the overhead of an evaluation per "rapid" step.

Darin

Jared Burns <jared-eclipse@xxxxxxxxx> Sent by: jdt-debug-dev-admin@xxxxxxxxxxx 08/01/2002 09:35 AM Please respond to jdt-debug-dev

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

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
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev