Concurrency in the Debug Platform

Last revised: Nov 26, 2004. Author: Darin Wright.

Problem

Many debug architectures require communicating with a remote debug target. The debug user interface needs to be robust in the face of latent and unreliable connections. To avoid blocking the user interface, the debug platform is exploiting the use of background jobs to perform operations and communicate with debuggers. As the opportunity for concurrent requests against debuggers increases, the platform must provide support for serializing conflicting requests against debuggers - for example a read operation to render a stack frame and a request that would invalidate the stack frame by resuming its thread. The debug platform needs to provide API and a set of guidelines to follow when scheduling concurrent operations and requests against debuggers.

Proposal

The classic cuncurrency issues

There are similarities between resources and debug elements and between resource modification and and performing operations on debug elements. Both are hierarchical in nature: a project contains folders and files, a debug target contains threads and stack frames. To support concurrent operations on resources care must be taken to properly lock the appropriate resources for updates. To properly support concurrent operations on debug elements, a similar locking scheme should be used. For example, in order to write to a file, a lock must be obtained on that resource. In order to step in a thread, a lock should be obtained on the thread.

Using the platform pattern

The resource platform uses scheduling rules to achieve resource locking, via a rule factory that generates rules for different types of operations. Similarly, the debug platform could provide a rule factory to create scheduling rules for operations on debug elements. There are two basic types of operations that can be performed on a debug element: access operations and modify operations.

• An access operation simply reads or accesses data from a debug element. Generally, concurrent accesses may be supported by a debug architecture, unless the architecture only allows for serialized requests to the remote target.
• A modify operation changes the state of a debug element. Generally, only one modify operations cannot be performed concurrently. However, the rules may be different in different architectures. For example, the Java debugger allows for step operations to be performed in different threads at the same time, where as other architectures only allow stepping in one thread.

Specializing concurrency support

Since different architectures may have different concurrency capabilities, the rules for performing concurrent operations must be provided by the architecture. The debug platform can provide a pessimistic rule factory as a default implementation for targets that do not provide their own rule factory. Debuggers that want to leverage extra concurrency must provide their own rule factory. The pessimistic rule factory would provide rules for serialized modify and access operations.

• A rule factory can be provided using the platform's adapter mechanism. For example, an IDebugRuleFactory adapter can be provided by an IDebugTarget

What does it mean to the debug platform?

The debug platform's actions that modify and access debug elements should do so using the appropriate scheduling rules. Note that the use of scheduling rules does not mean that jobs have to be used. For example, one can simply use the beginRule/endRule support on the job manager. An operation would consult a debug target's rule factory to obtain the appropriate rule. For example, a step operation on a stack frame would obtain the modify rule for the stack frame, and schedule a job to perform the step.

What does it mean to the debug implementor?

To maintain backwards compatibility, debug implementations are not required to do anything to work in the 3.1 debug platform. By default, a rule factory will be provided that serializes access and modification operations. To enable concurrent operations, a debugger can provide its own rule factory. For example the Java debugger would provide a rule factory to allow concurrent access operations within a debug target, and allow concurrent modification operations in different threads.

Debug models may use scheduling rules within their implementations, so that clients calling debug model APIs are enforced to use the proper rules. For example, the step implementation would use beginRule/endRule calls to the job manager when performing a step.

Why do we need this?

As we add perform more background operations in the debugger, and move communication out of the UI thread to the background, we need a mechanism so support concurrent operations on debuggers, and we have to let debuggers tell us what the concurrency rules are for their architectures.

For example, in a step operation the following sequence of events occurs:

• The step action initiates a step request on a stack frame (or its owning thread)
• A RESUME/STEP_OVER event is fired
• A timer is started in case the step takes longer than 500ms, in which case the debug view is updated to show a long running step.
• A SUSPEND/STEP_END event is fired
• The timer is canceled.
• The debug view refreshes, updating the thread label, and accessing the new stack frames in the thread.
• The variables view refreshes, accessing the variables in the stack frame and children of any expanded variables. This may require evaluations to compute logical structures. An evaluation may be performed to compute variable toString() values in the details pane, or in line in the variables view, depending on how the view is configured.
• Source lookup is performed on the top stack frame, and an editor is opened. Source lookup accesses the debug model to resolve a source name for a stack frame.

In the 3.1 debug platform the step request will be performed in a background job. As well, the debug and variables view content providers will retrieve content and generate labels in background jobs. Source lookup will also be performed in a background job. All of this is done to avoid blocking the UI thread while communicating with a debug target. As updating the variables view can trigger evaluations (effectively resuming the thread that has just suspended to compute toString()'s), this can interfere with rendering labels in the debug view, as it invalidates stack frames. As well, the step action re-enables when the step end event is received, allowing the user to initiate another step before the views update. This can cause the views to show partial information, and information in an error state as the thread resumes while labels are being generated. We either want all views to update before we allow another step to occur (via serialization of jobs), or allow the next step request to effectively cancel jobs that it makes obsolete. We may be able to leverage the shouldSchedule/shouldRun support in jobs to cancel jobs that are obsolete.

Findings

Last updated: Dec 3, 2004

Experimenting with a rule factory that clients can use to perform locking when communicating with (accessing and modifying) a debugger revealed the following:

• The potential for deadlock increases. Debug model implementations may already use Java's built-in synchronization to implement thread safety. The additional use of scheduling rules as locks increases the chance of deadlocks in the following scenario: a debug element obtains a VM lock on an object, and performs a function that eventually requires a scheduling rule lock while another thread holds the scheduling rule lock, and is waiting for the VM lock. This could be avoided if the same locking mechanism were used by the client and implementation, but that would require debug model implementations to change and publicize their locking implementation.
• Using the scheduling rule locks is expensive. Each access to a debug model would require the use of an access lock. Thus, simple operations take on larger overhead. For example, generating a label would require the following steps, which will have a performance impact.
  • retrieving the debug rule factory adapter for a debug element
  • getting an access scheduling rule from the factory for the element
  • locking on the rule
  • computing the label
  • releasing the lock
• The client doesn't know when a lock is required. Requiring the use of locks is aggressive, and will no doubt cause locking when no locks are needed. Debug model implementations often cache information in the model to avoid communication with the back end (for example element names, etc.). Thus, clients will perform locking, when the implementation doesn't require it. Only the implementation knows when a lock is required.
• Client code becomes more complex. Although I was able to reduce the code pattern to a simple try/finally block with a getLock(..) and releaseLock(..) method, code interacting with a debug model grows more complex, and harder to maintain.

Based on these findings, we believe it is up to debug model implementations to assure they are thread safe, performing their own synchronization as needed. Models that require serialized communication with a back end are also required to implement such behavior in their model. In terms of API, this is not a breaking change. In terms of behavior, it is a change that may expose concurrency issues in existing debug model implementations. Debug model implementations need to ensure they are thread safe.