debug/documents/Concurrency-Debug.html - www.eclipse.org/eclipse - Git at Google

 <html>
 <head>
 <title>Debug Concurrency Proposal</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>

 <body bgcolor="#FFFFFF" text="#000000">
 <h1>Concurrency in the Debug Platform</h1>
 <p>Last revised: Nov 26, 2004. Author: Darin Wright.</p>
 <h2>Problem</h2>
 <p>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.</p>
 <h2>Proposal</h2>
 <h2><b>The classic cuncurrency issues</b></h2>
 <p>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.</p>
 <h2><b>Using the platform pattern</b></h2>
 <p>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: <b>access</b> operations and <b>modify</b>
   operations.</p>
 <ul>
   <li>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.</li>
   <li>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.</li>
 </ul>
 <h2><b>Specializing concurrency support</b></h2>
 <p>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.</p>
 <ul>
   <li>A rule factory can be provided using the platform's adapter mechanism. For
     example, an <font face="Courier New, Courier, mono">IDebugRuleFactory</font>
     adapter can be provided by an <font face="Courier New, Courier, mono">IDebugTarget</font></li>
 </ul>
 <h2><b>What does it mean to the debug platform?</b></h2>
 <p>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.</p>
 <h2><b>What does it mean to the debug implementor?</b></h2>
 <p>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.</p>
 <p>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.</p>
 <h2><b>Why do we need this?</b></h2>
 <p>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.</p>
 <p>For example, in a step operation the following sequence of events occurs:</p>
 <ul>
   <li>The step action initiates a step request on a stack frame (or its owning
     thread)</li>
   <li>A RESUME/STEP_OVER event is fired</li>
   <li>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.</li>
   <li>A SUSPEND/STEP_END event is fired</li>
   <li>The timer is canceled.</li>
   <li>The debug view refreshes, updating the thread label, and accessing the new
     stack frames in the thread.</li>
   <li>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.</li>
   <li>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. </li>
 </ul>
 <p>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.</p>
 <h2><b>Findings</b></h2>
 <p>Last updated: Dec 3, 2004</p>
 <p>Experimenting with a rule factory that clients can use to perform locking when
   communicating with (accessing and modifying) a debugger revealed the following:</p>
 <ul>
   <li>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.</li>
   <li>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.
     <ul>
       <li>retrieving the debug rule factory adapter for a debug element</li>
       <li>getting an access scheduling rule from the factory for the element</li>
       <li>locking on the rule</li>
       <li>computing the label</li>
       <li>releasing the lock</li>
     </ul>
   </li>
   <li>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.</li>
   <li>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.</li>
 </ul>
 <p>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.</p>
 <p>&nbsp;</p>
 </body>
 </html>
	<html>
	<head>
	<title>Debug Concurrency Proposal</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body bgcolor="#FFFFFF" text="#000000">
	<h1>Concurrency in the Debug Platform</h1>
	<p>Last revised: Nov 26, 2004. Author: Darin Wright.</p>
	<h2>Problem</h2>
	<p>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.</p>
	<h2>Proposal</h2>
	<h2><b>The classic cuncurrency issues</b></h2>
	<p>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.</p>
	<h2><b>Using the platform pattern</b></h2>
	<p>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: <b>access</b> operations and <b>modify</b>
	operations.</p>
	<ul>
	<li>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.</li>
	<li>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.</li>
	</ul>
	<h2><b>Specializing concurrency support</b></h2>
	<p>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.</p>
	<ul>
	<li>A rule factory can be provided using the platform's adapter mechanism. For
	example, an <font face="Courier New, Courier, mono">IDebugRuleFactory</font>
	adapter can be provided by an <font face="Courier New, Courier, mono">IDebugTarget</font></li>
	</ul>
	<h2><b>What does it mean to the debug platform?</b></h2>
	<p>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.</p>
	<h2><b>What does it mean to the debug implementor?</b></h2>
	<p>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.</p>
	<p>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.</p>
	<h2><b>Why do we need this?</b></h2>
	<p>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.</p>
	<p>For example, in a step operation the following sequence of events occurs:</p>
	<ul>
	<li>The step action initiates a step request on a stack frame (or its owning
	thread)</li>
	<li>A RESUME/STEP_OVER event is fired</li>
	<li>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.</li>
	<li>A SUSPEND/STEP_END event is fired</li>
	<li>The timer is canceled.</li>
	<li>The debug view refreshes, updating the thread label, and accessing the new
	stack frames in the thread.</li>
	<li>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.</li>
	<li>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. </li>
	</ul>
	<p>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.</p>
	<h2><b>Findings</b></h2>
	<p>Last updated: Dec 3, 2004</p>
	<p>Experimenting with a rule factory that clients can use to perform locking when
	communicating with (accessing and modifying) a debugger revealed the following:</p>
	<ul>
	<li>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.</li>
	<li>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.
	<ul>
	<li>retrieving the debug rule factory adapter for a debug element</li>
	<li>getting an access scheduling rule from the factory for the element</li>
	<li>locking on the rule</li>
	<li>computing the label</li>
	<li>releasing the lock</li>
	</ul>
	</li>
	<li>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.</li>
	<li>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.</li>
	</ul>
	<p>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.</p>
	<p> </p>
	</body>
	</html>