A Concurrency-Agnostic Protocol for Multi-Paradigm Concurrent Debugging Tools
Stefan Marr, Carmen Torres Lopez, Dominik Aumayr, Elisa Gonzalez Boix, Hanspeter Mössenböck
AA Concurrency-Agnostic Protocol for Multi-ParadigmConcurrent Debugging Tools
Stefan Marr
Johannes Kepler UniversityLinz, Austria stefan . marr@jku . at Carmen Torres Lopez
Vrije Universiteit BrusselBrussels, Belgium ctorresl@vub . be Dominik Aumayr
Johannes Kepler UniversityLinz, Austria dominik . aumayr@jku . at Elisa Gonzalez Boix
Vrije Universiteit BrusselBrussels, Belgium egonzale@vub . be Hanspeter Mössenböck
Johannes Kepler UniversityLinz, Austria hanspeter . moessenboeck@jku . at Abstract
Today’s complex software systems combine high-level con-currency models. Each model is used to solve a specific setof problems. Unfortunately, debuggers support only the low-level notions of threads and shared memory, forcing devel-opers to reason about these notions instead of the high-levelconcurrency models they chose.This paper proposes a concurrency-agnostic debuggerprotocol that decouples the debugger from the concurrencymodels employed by the target application. As a result, theunderlying language runtime can define custom breakpoints,stepping operations, and execution events for each concur-rency model it supports, and a debugger can expose themwithout having to be specifically adapted.We evaluated the generality of the protocol by applying itto SOMns, a Newspeak implementation, which supports adiversity of concurrency models including communicatingsequential processes, communicating event loops, threadsand locks, fork/join parallelism, and software transactionalmemory. We implemented 21 breakpoints and 20 steppingoperations for these concurrency models. For none of these,the debugger needed to be changed. Furthermore, we visu-alize all concurrent interactions independently of a specificconcurrency model. To show that tooling for a specific con-currency model is possible, we visualize actor turns andmessage sends separately.
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. Copyrightsfor components of this work owned by others than the author(s) mustbe honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee. Request permissions from [email protected].
DLS’17, October 24, 2017, Vancouver, Canada © 2017 Copyright held by the owner/author(s). Publication rights licensedto Association for Computing Machinery.ACM ISBN 978-1-4503-5526-1/17/10...$15.00 https://doi . org/10 . . CCS Concepts • Software and its engineering → Con-current programming languages ; Software testing and de-bugging ; Keywords
Debugging, Tooling, Concurrency, Breakpoints,Stepping, Visualization
ACM Reference Format:
Stefan Marr, Carmen Torres Lopez, Dominik Aumayr, Elisa Gonza-lez Boix, and Hanspeter Mössenböck. 2017. A Concurrency-AgnosticProtocol for Multi-Paradigm Concurrent Debugging Tools. In
Pro-ceedings of 13th ACM SIGPLAN International Symposium on Dy-namic Languages (DLS’17).
ACM, New York, NY, USA, 12 pages. https://doi . org/10 . . Building and maintaining complex concurrent systems isa hard task. Some developers combine different high-levelmodels to solve problems with a suitable tool [Tasharofi et al.2013]. Unfortunately, debugging support for combined con-currency models is minimal, which makes building and main-taining complex concurrent systems even harder.For more than three decades, debugging support for con-currency models has been studied for each model in iso-lation [McDowell and Helmbold 1989]. As a result, thread-based languages such as Java and C/C++ have debuggersaware of threads and locks. Similarly, ScalaIDE and Erlangprovide support for actors and message sending.However, support for debugging combined concurrencymodels is still missing. The main challenge is to identify acommon representation for concurrency models so that adebugger does not need specialized support for each model.For example, there are four main interpretations of the ac-tor model, each of which has been implemented in differentvariations [De Koster et al. 2016]. For comprehensive debug-ging support of all these variations, a debugger needs toabstract from the concrete concurrency model and providea common set of abstractions instead. This would allow usto use the same debugger without changes for the differentconcurrency models and their numerous variations. a r X i v : . [ c s . P L ] O c t LS’17, October 24, 2017, Vancouver, Canada Marr et al.
This paper presents the Kómpos protocol, a concurrency-agnostic protocol to enable debuggers to support a wide rangeof concurrency models. Using the Kómpos protocol, webuilt the Kómpos debugger for online debugging of com-plex concurrent systems that combine communicating eventloops (CEL) [Miller et al. 2005], communicating sequentialprocesses (CSP) [Hoare 1978], software transactional memory (STM) [Harris et al. 2005], fork/join [Blumofe et al. 1995], andshared-memory threads and locks . Based on the concurrency-agnostic protocol, Kómpos supports a rich set of breakpointsfor the various concurrency abstractions, a rich set of step-ping semantics to explore program behavior, a generic vi-sualization of interactions between concurrent entities, aswell as an actor-specific visualization of turns and messagesends. This evaluation shows that the Kómpos protocol is (1)general enough to support advanced debugger features forshared-memory and message-passing models, and (2) thatit supports tools using the provided data independently ofany concurrency model, while preserving the ability to buildtools specific to a single model.Kómpos is a debugger for SOMns, a Newspeak implemen-tation [Bracha et al. 2010] based on Truffle [Würthinger et al.2012]. SOMns’ debugger support is built on Truffle’s tool-ing and debugger features [Seaton et al. 2014; Van De Vanter2015]. SOMns supports the five aforementioned concurrencymodels and implements breakpoints, stepping, and a tracingmechanism for them. Because of the concurrency-agnosticdesign of the Kómpos protocol, the Kómpos debugger isindependent from these concurrency models.The contributions of this paper are: • An analysis of the major shared-memory and messagepassing concurrency models to identify abstractionsfor a concurrency-agnostic debugger protocol. • A concurrency-agnostic debugger protocol that en-ables custom breakpoints, stepping, and visualization. • An implementation of the Kómpos protocol as part ofthe Kómpos debugger and SOMns. • An evaluation of the protocol based on CEL, CSP, STM,fork/join, and threads and locks.
This section discusses existing debugger protocols and intro-duces the Truffle debugger, on which we build our work.
Runtime systems and integrated development environments(IDE) typically communicate via a debugger protocol . Thisincludes the Java Debug Wire Protocol (JDWP), the GDB Java Debug Wire Protocol , Oracle Inc., access date: 2017-05-16, https://docs . oracle . com/javase/8/docs/technotes/guides/jpda/jdwp-spec . html machine interface, the Chrome DevTools protocol, and theVisual Studio Code debug protocol. These protocols define commands to interact with theprogram, to request information about threads, stack frames,local variables, objects, memory. They also communicateevents, e.g., when a breakpoint was hit. While the protocolsdiffer in format and structure, they cover a similar set ofcommon debugger features. For instance, they allow a userto define a breakpoint for a specific source location, possiblywith filters and conditions attached to it.The use of a debugger protocol also decouples runtimesystems and debuggers facilitating the construction of newtools. However, these protocols are often designed for se-quential or threaded languages. As such, their support fordebugging concurrency abstractions is rather limited. Forinstance, JDWP and GDB can show a list of running threadsor control execution of a particular thread. GDB also hassupport to request information about Ada tasks. In Chrome,a step-into-async operation is the only explicit support forconcurrent stepping. In short, the protocols are limited tothese specific concurrency concepts.Thus, custom breakpoints or stepping operations for con-currency models are not supported. Instead, the protocolssupport a fixed set of breakpoint and stepping operations.Any extension requires changing the protocol.In this paper, we argue that a protocol similar to the onesmentioned above forms a foundation for the basic debuggerfeatures, i.e., to interact with the program and request basicinformation such as values or local variables and objects.However, in contrast to the classical debugger protocols,we propose a concurrency-agnostic protocol that supportsa wide range of concurrency models. Our implementationin SOMns is inspired by the Visual Studio Code protocol(cf. section 5), but as detailed later, the Kómpos protocolabstracts completely from different breakpoints and steppingoperations and thereby provides the necessary flexibility tosupport custom semantics for different concurrency models.
SOMns is built on top of Truffle, a framework for AST-basedinterpreters [Würthinger et al. 2012]. Part of the frameworkis support for interpreter instrumentation, which is used, e.g.,for language-agnostic debugging and execution monitoring.The framework provides Truffle-languages with a classicbreakpoint-based debugger for sequential code [Seaton et al.2014], which we use in SOMns for the basic sequential step-ping and breakpoint support. GDB/MI Interface , The GNU Project Debugger, access date: 2017-05-16, https://sourceware . org/gdb/onlinedocs/gdb/GDB . html Chrome DevTools Protocol , Google, access date: 2017-05-16, https://chromedevtools . github . io/devtools-protocol/ VS Code Debug Protocol , Microsoft, access date: 2017-05-16, https://github . com/Microsoft/vscode-debugadapter-node/tree/master/protocol Concurrency-Agnostic Protocol for Concurrent Debugging Tools DLS’17, October 24, 2017, Vancouver, Canada
One key element of the framework is its use of tags forthe AST nodes [Van De Vanter 2017]. For the Truffle debug-ger support, a language annotates AST nodes with tags for
Statement , Call , and
Root . Based on these tags, the debug-ger determines the target nodes for line breakpoints, singlestepping, step over, and returning from a method. SOMnsuses the same mechanism for AST node tags to encode addi-tional information, which is used to recognize concurrency-related operations as well as generic syntax information suchas keywords. The Kómpos debugger can use this informationfor debugging and syntax highlighting.
This section analyzes concurrency models to identify thebasic concepts that need to be supported by a debugger pro-tocol to enable concurrency-related breakpoint and steppingoperations. As a basic categorization, we distinguish shared-memory and message-passing models [Almasi and Gottlieb1994]. We analyze instances for both types of models in-cluding threads and locks, STM, and fork/join parallelismas shared-memory models, and CEL and CSP as message-passing models. To account for more advanced debuggerfeatures, we also analyze what information would be neededto visualize these concepts.
Shared-memory models, as supported by e.g., C/C++, Java,C acquire operation to the correspond-ing release operation to see how they relate. That also helps to detect unbalanced acquire/release operations which, e.g,can lead to starvation if locks are not released. Similarly, forobject monitors, the debugger should allow developers toset a breakpoint on entering and exiting the monitor. Forcondition variables, stepping between the wait and notify operations allows developers to observe their effects on, andcommunication with other threads. From the point where athread is created in a program, the debugger should allowdevelopers to set a breakpoint on its execution, or to stepinto its execution. Similarly, when a thread terminates, thedebugger should allow developers to suspend execution ofthe thread that joins with it and waits for termination.The high-level interactions of threads entering monitorsand using locks or condition variables are also relevant forvisualization, which is useful for identifying unintended in-teractions or missing synchronization.
The CEL model is a variation of the actor model, used by lan-guages such as E [Miller et al. 2005] and AmbientTalk [Van Cut-sem et al. 2014]. The main concepts are actors, messages,promises, and turns. Actors are the active entities, each withits own event loop. Actors execute messages as turns , i.e.,one by one, in the order they are received. They contain aset of objects and interact via asynchronous messages be-cause actors do not share memory. Promises are eventualvalues . They can establish a data dependency between actors,e.g., as placeholders for the return value of an asynchronousmessage. Since the CEL model includes only non-blocking ab-stractions, promise values can be accessed only via callbacks,which are executed as turns on an actor.When debugging such CEL actors, developers should beable to step through turns of a specific actor to see whichmessages are received. This means, the debugger shouldcombine normal sequential stepping within a turn with theability to skip sequential operations and step to the next turn.When sending messages, suspending the actor’s executionbefore a message is sent would allow developers to inspectits parameters and target object. Similarly, following theexecution to observe how promises are resolved and howcallbacks on them are executed after resolution can helpdevelopers to identify communication issues or unexpectedvalues. For all these operations, the debugger should be ableto either explicitly step through them or define breakpoints.For a visualization, the high-level interactions of actorswith messages and promises are relevant. For example, avisualization of the order in which turns, i.e., messages areexecuted could help to identify synchronization issues andbad message interleavings.
The main concepts in CSP are processes, channels, and mes-sages. Processes are the active entities that execute code.Channels are first-class elements that connect processes and
LS’17, October 24, 2017, Vancouver, Canada Marr et al. allow them to communicate by passing messages with ren-dezvous semantics. A message is a specific datum exchangedvia a channel. Like CEL, CSP is a message passing model.However, CSP uses blocking semantics and has no notion ofturns, which makes it very different to CEL.For debugging, it should be possible to follow the sequen-tial execution of a process, from its creation to the end, likein threads. But, similar to CEL, the debugger should be ableto step through message sends, i.e., in this case channel op-erations, to identify the communication partners and theirstate, or put breakpoints on these operations. Furthermore, itshould account for the rendezvous semantics of channels, tostep from a receiver to the continuation in the sender. Thisis useful since channels can be passed around, which mightlead to the wrong processes communicating with each other.For visualization, the communication between processesand the run-time network of channels is relevant, e.g., toidentify communication partners or lack-of-progress issues.
STM provides a wide range of notions for transactions, e.g.,open or closed, optimistic or pessimistic. For brevity, thisanalysis includes only the basic concepts of threads and trans-actions. Threads are the same as for other shared-memorymodels. Transactions, on the other hand, introduce a dy-namic scope, in which all modifications to shared state areapplied either atomically or not at all.The debugger should be able to interact with transactionsin a way that makes it possible to observe the behavior whentransactional conflicts occurs. Thus, developers should beable to set breakpoints or step through the execution oftransactions to the final commit operation. Being able tostop right before a transaction commits allows developers toexamine transaction interactions. The developer should alsobe able to step between transactions to follow the high-levelflow of program elements interacting on shared state.For a visualization, the transactions executed on threadsand their ordering could help to identify missing synchro-nization, unintended dependencies, or performance issues.
Fork/Join programming enables parallel divide-and-conqueralgorithms. The main abstraction is an asynchronously exe-cuting task, which produces a result eventually. The model isonly concerned with decomposing problems into a structureof tasks that synchronize based on fork and join operations.Other forms of synchronization are left out of the model.A debugger should focus on these fork and join operations.Breakpoints and stepping should enable developers to ex-plore the recursive structure of spawns and joins. Visualizingthese spawn and join dependencies may help to understandthe recursive nature of complex fork/join programs.
The above discussion identified the main concepts for CSP,CEL, F/J, STM, and T&L. This section categorizes them toestablish abstractions for a debugger protocol.
Activities are the active entities executing code. Thisincludes threads, actors, processes, and fork/join tasks.
Dy-namic scopes are well-structured and nested parts of a pro-gram’s execution during which certain concurrency-relatedproperties hold, e.g., during a transaction, while executingcode under an object monitor, or during an actor turn.
Pas-sive entities are entities that do not act themselves, but areacted upon. For example, we consider messages and promisesas passive entities of the CEL model, while the ones of CSPare channels and messages. Note that we do not considernormal objects as passive entities, because it was not needed.To model interactions between these entities, we use sendand receive operations. A
Send Operation is an interactionthat initiates communication or synchronization. A
ReceiveOperation , is an interaction that reacts to a communicationor synchronization operation. Consequently, we consider ac-quiring a lock or signaling a condition to be send operationsand joining with a thread is a receive operation.Table 1 gives an overview of the identified categories perconcurrency model. These categories of entities and opera-tions are used as foundation for the Kómpos protocol anddetailed in the following section.
To build a concurrency-agnostic debugger, we devise a proto-col for communication between the debugger and interpreterthat can support the breakpoints, stepping operations, andvisualizations envisioned in section 3, without merely enu-merating the concurrency concepts. The goal is that only thelanguage implementation knows the specifics for each con-currency model, while the debugger remains independentof them. Figure 1 shows the architecture of such a system.An interpreter with support for various concurrency modelsis connected to a debugger via the concurrency-agnosticKómpos protocol.
From section 3.6 we derive that concurrency concepts rele-vant for breakpoints, stepping operations, and visualizationcan be modeled based on activities , dynamic scopes , passiveentities , send operations , and receive operations . Using thesebasic notions, a protocol is independent of any specific con-currency model. However, the debugger requires meta datato match debugging operations and concrete concurrencyconcepts. Thus, when the debugger connects to the inter-preter, it receives meta data with details on the supportedconcurrency models, the entities they define, their break-points, and their stepping operations. This information is Concurrency-Agnostic Protocol for Concurrent Debugging Tools DLS’17, October 24, 2017, Vancouver, Canada
Table 1.
A Taxonomy of Concurrency Concepts Relevant for Debugging.
T&L CEL CSP STM F/JActivities threads actors processes threads tasksDynamic Scopes object monitors turns transactionsPassive Entities conditions messages channelslocks promises messagesSend Operations acquire lock send message send messagesignal condition resolve promiseReceive Operations release lock receive message join thread join taskwait for condition join processjoin thread
Interpreter DebuggerCEL CSPThreads&Locks STMFork/JoinDebugging Support Kómpos ProtocolSOM NS Kómpos
Figure 1.
General architecture: Interpreter and debuggercommunicate via the concurrency-agnostic Kómpos protocol.The interpreter provides the implementation of the differentconcurrency models and debugging support.mostly opaque to the debugger. For breakpoints and stepping,it is sufficient to match opaque identifiers (cf. section 4.3).
Concurrency Concepts.
As discussed in section 3.6, activi-ties are active entities that execute code. The debugger pro-tocol uses this notion, e.g., to offer stepping operations thatare specific to an activity type.
Dynamic scopes are used, forinstance to determine possible stepping operations. Somestepping operations are only available during a transactionor while holding an object monitor.
Passive entities , send , and receive operations are used forthe visualization of concurrent interactions. However, theyare currently not used in the context of pausing/resumingprogram execution or performing step-by-step execution. Debugger Concepts.
For debugging, the protocol includesvarious other concepts. For brevity, we discuss only the onesdistinct from other debugger protocols (cf. section 2.1).A source is either a file or some other form of source text.The source text has to be annotated with source tags to iden-tify the semantic elements contained in a source range. Forinstance, tags can indicate the source locations of messagesends or lock operations so that the debugger can show break-points or stepping operations. As mentioned in section 2.2,SOMns employs Truffle’s tagging mechanism to annotate atomic { int b = this.fieldB; this.fieldA = b + 1;} actType scopes threadthreadthread transactiontransaction
Atomic
Figure 2.
Example program using an atomic transaction. Thedebugger recognizes the atomic keyword via the
Atomic tag.When execution suspends at one of the three program pointsindicated with a number, the debugger receives location,indicated activity type, and active dynamic scopes.AST nodes in the interpreter. The Kómpos protocol is usedto send this information to the debugger.A breakpoint type defines suspension points, which maybe related to concurrency concepts. For example, one break-point type could be for the point where a message is receivedby an actor. They are distinguished by name and define whichsource tags they apply to. Thus, the debugger does not needto know the relationship between tags and breakpoints. In-stead, it can treat tags as opaque identifiers.A stepping operation type defines an operation to followprogram execution sequentially or concurrently. Similar tobreakpoint types, stepping operation types are distinguishedby name. Furthermore, they define criteria to determinewhether the operation is applicable in the current dynamiccontext. Such applicability criteria include source tags, theactivity type executing the currently suspended code, as wellas the dynamic scopes active for the current execution.
This section discusses an example to illustrate the protocol.Consider the program fragment in fig. 2 that uses an atomic block to ensure that the fieldA of an object is updated with-out interference by other threads.The figure indicates three possible program points with anumber, in which execution can be suspended for the atomic
LS’17, October 24, 2017, Vancouver, Canada Marr et al. block. Further, it shows that the atomic block is known tothe debugger via the
Atomic tag, which it received as partof the meta data and source information. When execution issuspended, the debugger received the source location, theactivity type, and active dynamic scopes, which are depictedin the right hand side of the figure. From the meta data andthe
Atomic tag associated with the source location for ○ ,the debugger can derive that it can offer a breakpoint that istriggered right before a transaction is started.Setting the breakpoint sends a BreakpointUpdate mes-sage to the SOMns interpreter, which includes the sourcelocation and the chosen breakpoint type. Afterwards, theprogram can stop at the atomic keyword, and the interpretersends a
Stopped message to the debugger. The message saysthat execution is suspended at location ○ , and that the cur-rent activity is a thread with a specific id. Based on this lo-cation information, source tags, and execution information,the debugger can derive the applicable stepping operations.Note that in this case there is no concurrent stepping applica-ble. However, all stepping operations are handled uniformly.When the debugger determines the stepping operations for ○ , the resulting set contains only the sequential steppingoperations that always apply, e.g. step into and step over.When the developer chooses the step-into operation, thedebugger sends a Step message to the interpreter, which in-cludes the thread id and the chosen stepping operation. Afterthe interpreter performs this step, execution is suspendedat ○ and the debugger receives again the current locationand activity. It also receives the information that a dynamicscope for a transaction is active. Based on this scope, it canoffer extra stepping operations, e.g., to step right before orafter the commit for the transaction. When executing thesestepping operations, execution would continue either to ○ ,or to the first statement after the atomic block. This section details the protocol. While we discuss its seman-tics, we refrain from prescribing a specific implementation,since we consider the ideas to be applicable to wide rangeof concrete debugger protocols. A concrete prototype imple-mentation is discussed in section 5.The protocol assumes bidirectional communication be-tween interpreter and debugger, which could be realizedwith remote function calls, messages on sockets, etc.Figure 3 shows an overview of the main concepts used bythe Kómpos protocol. We distinguish between (1) debugging-specific messages exchanged between debugger and inter-preter, (2) trace data sent from the interpreter for visualiza-tion, and (3) a general meta-data description used to interpretthe exchanged messages. We detail each of them below.
Debugger Messages.
For stepping and breakpoints, the Kóm-pos protocol uses the first four debugger messages in fig. 3.
Meta ModelDebugger Messages Trace Events
ActivityTypecreation: byte completion: byteicon: string EntityTypeid: typeIdlabel: stringDynamicScopeTypestart: byte end: byte PassiveEntityTypecreation: byteBreakpointTypename: stringlabel: stringapplicableTo: Tag[] SteppingTypename: stringlabel: stringapplicableTo: Tag[]activities: ActivityType[]scopes: DynamicScopeType[]SendOperationTypemarker: byteentity: EntityTypetarget: EntityType ReceiveOperationTypemarker: bytesource: EntityTypeSourceURI: URI sourceText: stringlocations: TaggedCoord[]BreakpointUpdatelocation: Coordtype: BreakpointTypeStoppedactivityId: idlocation: CoordactType: ActivityTypescopes:DynamicScopeType[]StepactivityId: idtype: SteppingTypeSymbolssyms: Map
Figure 3.
Class diagram of the main elements of the Kóm-pos protocol. The meta model describes the concurrencyand debugger concepts supported by the interpreter, andprovides the debugger with the meta data to identify whenand where breakpoints and stepping operations are applica-ble. Debugger messages are used to update the debugger orinterpreter. Trace events encode an execution trace used forvisualization. Trace events are prefixed with a marker byte.The
Source message provides the source information tothe debugger. Since the debugger is to be agnostic from spe-cific concurrency concepts, as well as incidentally from a spe-cific language, we provide source information explicitly. Themessage includes a URI to identify the source file or resource,the source text, and a list of tagged source locations. Sourcelocations specify the exact coordinates, for instance basedon a line number, column number, and character length. Thetags are merely opaque identifiers which identify concur-rency operations, e.g., as seen with the
Atomic tag in fig. 2.
Concurrency-Agnostic Protocol for Concurrent Debugging Tools DLS’17, October 24, 2017, Vancouver, Canada
The
BreakpointUpdate message is used to communicatebreakpoints from the debugger to the interpreter. It encodesthe source location and the breakpoint type.The
Stopped message is sent from the interpreter to thedebugger to indicate that either a breakpoint was hit or a step-ping operation completed. It identifies the current locationand the suspended activity with id and type. Furthermore, itincludes a list of currently active dynamic scopes for this ac-tivity. Note that the activity type and active dynamic scopescan also be determined from the trace data, but providingthem explicitly simplifies the debugger implementation.Finally, the
Step message is sent from the debugger to theinterpreter to instruct the latter to resume execution of aspecified activity with a given stepping type.The last message listed in fig. 3, called
Symbols message, isan optimization. It avoids sending long strings repeatedly bysending a symbol table from the interpreter to the debugger.
Execution Trace Data.
To provide details about the execu-tion of a concurrent program, the Kómpos protocols usestrace events that encode the program’s behavior with 7 dif-ferent trace entries. We use these trace events for instanceto visualize concurrent interactions. In general, each traceevent starts with a marker, which is indicated by the dashedline in fig. 3. The relation between the concrete marker anda concurrency concept is defined via the meta data discussedin the following subsection.An
ActivityCreation event records the id of the createdactivity, its name, and the source location of the creation op-eration. An
ActivityCompletion event is merely a markerrecording that an activity terminated. The correspondingactivity id can be determined from the complete trace. A
ScopeStart event records the beginning of a dynamic scope.It records the id of a scope, which corresponds to, e.g., themessage id for an actor turn. It also includes the source loca-tion for the scope, e.g., the method invoked for a turn, or theatomic code block for a transaction. A
ScopeEnd event is alsoa marker that can be matched to the scope start implicitly. A
PassiveEntityCreation event records the id of the passiveentity created and the source location of the operation.Interactions are recorded as
SendOperations with the idof the involved passive entity, e.g., channel or message, andthe target entity id, e.g., the receiving actor. Informationabout the sending entity can be inferred from the trace basedon the dynamic scope or current activity.
ReceiveOperations encode merely the id for the source entity which is for in-stance a channel or fork/join task.
Meta Data Description.
The debugger messages and traceevents discussed above are completely independent fromconcurrency models. To distinguish different types of enti-ties and interactions, the interpreter sends meta data to thedebugger when the connection is initialized. The meta dataconsists of the 8 concepts shown at the top of fig. 3. There exist three types of entities:
ActivityType , Dyna - micScopeType , and the PassiveEntityType . EntityType defines data common to all entity types. All entities havea label, i.e. a name, and a unique id to distinguish them.
ActivityType additionally defines unique trace event markerfor activity creation and completion, as well as an identifierfor an icon to be used in the user interface.
DynamicScopeType defines the start and end markers for scopes, and
Passive - EntityType defines creation marker.The
BreakpointType defines the possible breakpoints.Each type has a unique name, a label to be used in the userinterface, and an applicability criterion based on source tags.If a source location has one of the listed tags, then it supportsthe breakpoint. If a breakpoint type does not specify anysource tags, it applies to all source locations.The
SteppingType defines the stepping operations. Eachtype has a name and label. As for breakpoints, source tagsalso define whether a stepping operation is applicable. Forinstance, the operation to step to the receiver of a messageis only available on a message-send operation. An additionalapplicability criterion is the current activity type, e.g., toenable stepping to the next turn for actors. Similarly, steppingcan be conditional to the current dynamic scope. As suchthe third applicability criterion is the current scope type. Forinstance, some transaction-related stepping operations areonly useful within a transaction (cf. section 4.2).Finally, the meta data specifies how to interpret
Send - Operations and
ReceiveOperations . For each operation,a unique marker is defined. For a send, the operation typespecifies the entity types for the involved entity and targetto identify which set of entities it belongs to. Similarly, for areceive operation, the type of the source entity is specified.This meta data makes it possible to handle breakpointsand stepping operations in an abstract manner. Furthermore,it becomes possible to interpret the trace events either gener-ically or specific to a concurrency model to visualize them.We evaluate both aspects in section 6.
This section provides basic details on our implementation,which is used for the evaluation. The Kómpos debugger isa TypeScript application running in a browser. The SOMnsinterpreter implements the support for the concurrency mod-els, their breakpoints, stepping semantics, and executiontracing. As shown in fig. 1, the SOMns interpreter and theKómpos debugger communicate via a bi-directional connec-tion, for which we use Web Sockets. JSON is used to encodethe meta data and debugger messages. For efficiency, thetrace events are sent through a separate binary web socket.When the Kómpos debugger connects to SOMns, the in-terpreter sends the meta data to initialize the debugger. The The WebSocket Protocol , IETF, access date: 2017-05-16, https://tools . ietf . org/html/rfc6455 LS’17, October 24, 2017, Vancouver, Canada Marr et al. debugger then processes the meta data to enable efficientparsing of trace events, to initialize breakpoints, steppingoperations, and visualizations. Based on the labels providedas part of the meta data, the Kómpos debugger also inter-prets the meta data to enable filtering and querying datafor specific concurrency models, which can be used to buildtools specific to a concurrency model.When a program executes in the SOMns interpreter, itsends source code and source tags as part of the
Source mes-sage to the debugger. The Kómpos debugger uses this data todisplay the code, indicate possible locations for breakpoints,and also apply syntax highlighting based on the tags. Thisapproach makes the debugger completely language-agnostic.When the program hits a breakpoint or completes a step,the debugger uses the data from the
Stopped message tohighlight the source location. It also uses the meta data andinformation about current activity type and active dynamicscopes to select the possible stepping operations. To obtaininformation on the stack trace and local variables, we usemessages similar to the Visual Studio Code debugger proto-col (cf. section 2.1). As a result, we can also use Visual StudioCode as debugger for SOMns, for sequential debugging.One challenge for the correct implementation of a concur-rent debugger such as Kómpos is that interactions betweenthe interpreter and debugger need to handle data races. Forinstance, there is a race between the two web socket con-nections, because the order, in which messages are receivedbetween the two connections, is not guaranteed. This canbe problematic because we might hit a breakpoint for whichthe debugger does not yet know the corresponding activ-ity. We solve this in the debugger by using promises for theactivities, which delays handling for the debugger messageuntil all data is available. Similarly, a trace event can also usea symbol id, for which the full string was not yet receivedvia the Symbols message. For trace events, we handle theseraces by waiting for all dependent data elements before atrace event can be used further.
General Requirements
For an application of the Kómposprotocol to other systems, we see as a main requirementthe information about the lexical location of concurrencyoperations. While we leverage Truffle’s approach of anno-tated AST nodes, the information can also be obtained frombytecodes or with static analysis. A larger hurdle for adop-tion could be the implementation of the necessary runtimesupport for stepping, breakpoints, and trace events inside anexisting VM or runtime system. It might require substantialchanges to ensure an efficient implementation and providethe fine-grained stepping semantics as provided in SOMns.Generally, Truffle’s AST-based implementation and optimiza-tions are convenient, but not essential. Similarly, the protocol SOM ns VS Code Extension , access date: 2017-05-16, https://github . com/smarr/SOMns-vscode is language and concept agnostic, and thus, can be appliedto a wide range of systems. This section evaluates the Kómpos protocol with respect toits ability to support breakpoints, stepping operations, and vi-sualizations. The goal of the evaluation is to demonstrate thatthe protocol is agnostic of specific concurrency abstractionsand general enough to support a wide range of concurrencymodels. We base the evaluation on the five aforementionedmodels: CEL, CSP, fork/join, STM, and threads and locks.These models are chosen for their different concurrencycharacteristics, and for being the main programming modelsin the field. All reported experiments are implemented aspart of SOMns and the Kómpos debugger [Marr et al. 2017]. To evaluate the flexibility of the system to represent variousbreakpoints, we apply the analysis results of section 3 toSOMns. Specifically, we identify and implement 21 differentbreakpoints that can be used to pause execution based on theconcurrency abstractions and their interactions. As a generalprinciple, we consider the point in time right before or aftera concurrent operation as potentially relevant. The goal is toallow developers to observe the effects of an operation thatmight interleave with other operations in the system. Thebreakpoints are listed with a brief description in table 2.With the concepts of the Kómpos protocol presented insection 4.3, we were able to model all breakpoints solely byspecifying the source tag to identify the source locations theyapply to. No specific support was required in the debugger.The breakpoint implementation is thus completely confinedto the interpreter, where the concurrency operations areimplemented. Arguably, the Kómpos protocol allows devel-opers to define arbitrary breakpoints specific to concurrencyoperations, or other kind of language constructs.
To evaluate the Kómpos protocol’s support for standard andadvanced stepping operations, we apply the results of theanalysis in section 3 and implement 20 different stepping op-erations. Guided by the breakpoints in table 2, we identifiedstepping operations that allow one to follow the executionflow between various potential points of interest. The step-ping operations are listed with a brief description in table 3.With the Kómpos protocol, we were able to model allthose stepping operations and customize their applicabilitybased on a current source location, the type of the currentactivity, or active dynamic scopes. Other than these genericconcepts, no support is required in the debugger. Similar tothe breakpoint support, the stepping operations are defined SOM ns and the Kómpos Debugger Protocol , access date: 2017-05-16, https://github . com/smarr/SOMns Concurrency-Agnostic Protocol for Concurrent Debugging Tools DLS’17, October 24, 2017, Vancouver, Canada
Table 2.
Set of breakpoints implemented in SOMns. None of the breakpoints requires special support in the Kómpos protocol.Instead, they are all implemented based on meta data that includes name and source tag.
Models Name Description Source Tagall activity creation before an actor, process, task, or thread is created
ActivityCreation
CSP, F/J, T&L activity execution before first statement of the new activity is executed
ActivityCreation
CSP, F/J, T&L before join before waiting that a process, task, or thread completes
ActivityJoin
CSP, F/J, T&L after join after a process, task, or thread completed execution
ActivityJoin
CEL actor message send before an actor message is sent
EventualMessageSend
CEL actor message receiver before first statement of message is processed in the receiver
EventualMessageSend
CEL before async. method activation before the first statement of a method activated by an async. msg send
EventualMessageSend
CEL after async. method activation before returning from a method activated by an async. msg send
EventualMessageSend
CEL before promise resolution before a promise is resolved with a value or error
PromiseCreation
CEL on promise resolution before the first statement of all handlers registered on promise
PromiseCreation
CSP before channel send before executing the send on a channel (set on send operation)
ChannelWrite
CSP after channel receive after receiving a message from a channel (set on send operation)
ChannelWrite
CSP before channel receive before receiving a message from a channel (set on receive operation)
ChannelRead
CSP after channel send after sending on a channel (set on receive operation)
ChannelRead
STM before transaction before starting a transaction
Atomic
STM before commit before attempting to commit changes of a transaction
Atomic
STM after commit after committing the transaction succeeded
Atomic
T&L before acquire before attempting to acquire a lock
AcquireLock
T&L after acquire after acquiring a lock
AcquireLock
T&L before release before releasing a lock
ReleaseLock
T&L after release after releasing a lock
ReleaseLock completely in the interpreter, where the concurrency opera-tions are implemented. This demonstrates that the Kómposprotocol provides the desired flexibility to define arbitrarystepping operations.
Finally, we evaluate whether the data provided by the Kóm-pos protocol can be used for visualizations. To this end, as-sess whether it is possible to built a visualization that isagnostic to the concurrency models as well as one that isspecifically designed for one concurrency model. The goalis to identify where the boundary is between concurrency-agnostic aspects and special-purpose constructs. We built:(1) an agnostic visualization of interactions between entitiesin a program, and (2) a visualization specific to the actormodel which shows the execution of actor turns and theircausal relationships based on the messages sent in a turn.
The system interaction visualization shows how entities com-municate with each other. Figure 4 shows a screenshot ofthe visualization. Activities are visualized as rectangles withrounded corners. Depending on the number of activities cre-ated from the same source location, the visualization groupsthe activities. Furthermore, the debugger chooses a differentcolor range depending on the activity type. On the otherhand, the icon in front of an activity’s name is directly spec-ified as part of the meta data (cf. fig. 3). An
ActivityType includes a name for an icon, for which the debugger can thendetermine a suitable visualization.Passive entities are visualized with custom SVG graphics.Figure 3 shows channels as two white arrows on top of a !! Platform !! ReportActor !! DataActor !! JsonInputActor !! InputGeneratorActor ↯↯ λ buildParallelSumTreefromto@371@40:: (9) ↯↯ λλ calculateSumOfwithfrominto@386@12@387@52 (9) ⧭⧭ JsonStreamTokenizer ⧭⧭ DataFilterProcess
Figure 4.
Screenshot of the system interaction visualizationin Kómpos. Activities are represented as rectangles. The de-bugger assigns color ranges to an activity type, e.g., green foractors, yellow for processes, and red for tasks. Color shadesdistinguish between activities of the same type. Black arrowsrepresent messages sent and gray dashed arrows indicatewho created an entity. Black bars with two white arrowsare a custom visualization for channels. The visualization ischosen via an optional map using an entity type’s label.black bar. The visualization is generated in the debuggerand matched to a
PassiveEntityType based on its label.The goal was to make these entities easier to recognize. Thedesign tradeoff here is between including more meta datain the protocol and leaving room for the debugger to addcustom visualizations like this. We decided that the simplestwould be to have an extensible map in the debugger to selecta specific visualization for entities it is aware of.
LS’17, October 24, 2017, Vancouver, Canada Marr et al.
Table 3.
Set of stepping operations implemented in SOMns. None of these stepping operations require special support in theKómpos protocol. Instead, they are realized solely based on the applicability criteria provided as part of the meta data.
Model Name Description Criteriaall resume continue execution of current activityall pause pause execution of current activityall stop terminate programall step into step into method callall step over step over method callall return return from method callCSP, F/J, T&L step into activity halt new activity before execution of the first statement source tag:
ActivityCreation
CSP, F/J, T&L return from activity halt activity that joins with the current one, after joining current activity: Process, Task, ThreadCEL step to message receiver halt activity before executing the first statement of a received message source tag:
EventualMessageSend
CEL step to promise resolver halt activity before resolving a promise source tag:
PromiseCreation
CEL step to promise resolution halt all activities before executing the first statement of handlers regis-tered on a promise source tag:
PromiseCreation
CEL step to next turn continue current actor’s execution and stop before the first statementof the next executed message current activity: ActorCEL return from turn to resolution continue current actor’s execution and stop before the execution of thefirst statement of all handlers registered on a promise that is resolvedby the current turn current activity: ActorCSP step to channel receiver halt activity reading from a channel to receive the sent message source tag:
ChannelWrite
CSP step to channel sender halt activity sending to a channel source tag:
ChannelRead
STM step to next transaction halt activity before starting the next transactionSTM step to commit halt activity before committing a transaction dynamic scope: TransactionSTM step after commit halt activity after committing a transaction dynamic scope: TransactionT&L step to release halt activity before releasing a lock dynamic scope: monitorT&L step to next acquire halt the next activity right after acquiring the current lock dynamic scope: monitor
The gray-dashed arrows between entities, i.e., activities orpassive entities, are determined based on their creation infor-mation. The visualization does not show dynamic scopes. Itmerely uses them to identify the connection between entities.Actor and channel messages are not shown because we donot record their creation, but rather the specific send/receiveoperations. Thus, the visualization itself is agnostic fromthe concurrency models, but it depends on how the data isencoded in trace events for a specific concurrency model.Send/receive events are used for the black arrows. Entitiesexchanging more messages are displayed closer together.Overall, the system interaction visualization is indepen-dent of specific concurrency models. It just uses the knowl-edge about activities, dynamic scopes, passive entities, cre-ation operations, and send/receive operations to generatea graph representing the systems interaction. For most as-pects, the debugger independently visualizes the elements,colors, and icons considering only meta data provided by theinterpreter. However, to provide the extra bit of polish, i.e.,to provide an iconic representation of channels, it includes amap of additional visualizations that matches entity type la-bels. We consider this design a reasonable tradeoff that showsthat small customizations are possible, but a concurrency-agnostic visualization is feasible.
Figure 5 shows our second visualization which is inspiredby the processes view in Causeway [Stanley et al. 2009]. Thegoal of this visualization is to show the causality betweenturn executions and messages. It visualizes each actor in ! Platform ! Pong ! Ping
Figure 5.
Screenshot of the actor turn visualization in Kóm-pos. Each actor is shown on a lane with its turns indicated ascircles. Lines between turns indicate message sends. Whenexpanding a turn, it shows the order of the messages sent.the system on a lane, on which its turns are indicated ascircles. A line indicates the message that caused a turn. Wheninspecting a specific turn, it unfolds into an ellipse and showssent messages (as rectangles) in the order they were sent. Themessages connect with arrows to the turns on the receivingactor that processes them.While this visualization is specific to the actor model,parsing and interpreting of the trace events is still done inan agnostic way. Only after obtaining the data, the Kómposdebugger uses the meta data to determine which activitiesare actors, which dynamic scopes are turns, and which sendoperations are actor messages.This visualization is specific to the notion of communicat-ing event loops, and its implementation makes assumptionsabout which interactions are possible. Nonetheless, it is basedon Lamport’s general happens-before relationship [Lamport1978], which can be applied to other concurrency models,
Concurrency-Agnostic Protocol for Concurrent Debugging Tools DLS’17, October 24, 2017, Vancouver, Canada too. Moreover, its implementation in Kómpos is based on theabstract notions of the protocol, and merely filters out theactor-related trace events. Thus, it seems feasible to extentit to other concurrency models, especially if they use forinstance transactions or object monitors as dynamic scopes,to indicate their causal relations.
The evaluation shows that the Kómpos protocol is abstractenough to support arbitrary breakpoints and stepping op-erations independent from a specific concurrency model.Furthermore, the provided data is generic enough for toolsthat are agnostic of the concurrency models as shown withour system interaction view. However, it remains possible tobuild tools specific to a concurrency model by interpretingthe meta data, as we have shown with the actor turn view.
This section discusses concurrent debuggers and novel IDEdesigns that influenced our work or that are closely related.Debugger protocols similar to ours and their limitations havebeen discussed in section 2.1. Generally, their support forconcurrency models is minimal and they do not provide anyfacilities for custom breakpoint or stepping types, while theKómpos protocol is designed for this purpose.
Debuggers for concurrent and parallel systems have a longhistory [McDowell and Helmbold 1989]. This includes sup-port for breakpoints, stepping, and visualizing of parallelsystems. However, to the best of our knowledge, so far, nodebugger supports a wide range of concurrency models.REME-D [Gonzalez Boix et al. 2014] is the closest relatedwork. It is also an online debugger focusing on distributedcommunicating event-loop programs, that uses a meta-pro-gramming API to realize breakpoints and stepping semantics.Our actor breakpoint and stepping operations are reminis-cent of REME-D’s ones. However, REME-D’s API is specificto the actor model, and does not abstract from concurrencyconcepts as the Kómpos protocol does.Erlang and ScalaIDE support basic debugging of actorprograms with sequential stepping and breakpoints. ScalaIDEalso includes an option to follow a message send and stop inthe receiving actor. However, neither of them attempts to gobeyond this basic debugger functionality.Zyulkyarov et al. [2010] introduced a debugger for a trans-actional system. The focus of their work is to ensure thatthe STM implementation does not interfere with the debug-ging experience, and that stepping over or into transactions Debugger , Ericsson AB, access date: 2017-05-16, http://erlang . org/doc/apps/debugger/debugger c hapter . html Asynchronous Debugger , ScalaIDE, access date: 2017-05-16, http://scala-ide . org/docs/current-user-doc/features/async-debugger/index . html works naturally. Furthermore, they provide mechanisms forconflict-point discovery and debug-time transactions. Ourwork, however, focuses on advanced breakpoint and steppingsemantics. Their advanced debugging mechanisms would behighly interesting for Kómpos, too.Early prototypes of the Kómpos debugger were presentedby Torres Lopez et al. [2016] and Marr et al. [2017]. However,this was only an exploration of initial ideas and did not yetinclude any work on the Kómpos protocol. Projects such as the Language Server Protocol, which isimplemented by Visual Studio Code, and Monto [Keidel et al.2016] try to change how we think about integrated devel-opment environments (IDEs). Instead of using the pluginapproach common to Eclipse or Visual Studio, they providesupport for languages by providing a common protocol toexchange information for code completion, code errors, andother common IDE services. We consider their design aninspiration for this work. However, neither the languageserver protocol nor Monto support debugging at this point.With respect to flexible debuggers, Ressia et al. [2012]explored how to bring the abstraction level from a stack-centered view to the object level introducing higher-levelstepping operations and breakpoints. Chiş et al. [2015] fol-lowed this line of work with a debugger framework fordomain-specific debuggers. They support domain-specificbreakpoints, stepping operations, and debugger views. Forexample, they have a debugger for a parser framework to stepthrough the parsing process on the level of the parser rulesinstead of the parser implementation. Similarly, they have adebugger for a complex notification system to step throughthe activations of the subscriptions to notifications insteadof working on the basic notion of method calls and callbacks.Instead of providing a framework for building debuggers,our work focuses on the protocol between the debugger andthe interpreter. To our understanding, our protocol supportsall required elements to also support their domain-specificbreakpoint and stepping operations. However, we do notprovide a framework to build custom debugger interfaces asthey do. To enable better debugging tools for complex concurrent ap-plications, we propose the Kómpos protocol, a concurrency-agnostic debugger protocol. The protocol abstracts from spe-cific concurrency models to support custom breakpoints,stepping operations, and visualizations, without requiringsupport for the specific concurrency models.Based on our study of shared-memory and message-passingmodels, the protocol represents concurrency concepts in Language Server Protocol , Microsoft, access date: 2017-05-16, https://github . com/Microsoft/language-server-protocol LS’17, October 24, 2017, Vancouver, Canada Marr et al. terms of activities, dynamic scopes, and passive entities. Ituses opaque meta data to allow the debugger to determinewhere breakpoints or stepping operations are applicable.The protocol also includes the notion of send and receiveoperations to, e.g., visualize concurrent interactions.To evaluate the protocol, we implemented it in the Kómposdebugger and SOMns. SOMns supports the five major con-currency models: threads and locks, communicating eventloops, communicating sequential processes, fork/join paral-lelism, and software transactional memory. We implemented21 breakpoints and 20 stepping operations in SOMns forthese models, without requiring any modifications to thedebugger, which shows that the protocol is concurrency ag-nostic. We also implemented two visualizations. The first oneshows the concurrent interactions independently of the con-currency models. The second one shows causalities betweenactor turns, messages, and their ordering, which is specificto the communicating event-loop model. This demonstratesthat the protocol is flexible enough to enable advanced de-bugging tools that are concurrency agnostic, while it remainspossible to build tooling specific to a concurrency model.Based on this work, existing debugger protocols could beextended to provide advanced debugging support for con-current programming, without requiring support for specificconcurrency models. This provides a foundation for bettertooling and debuggers for complex concurrent systems thatcombine concurrency models.For future work, we would like to study how to enablearbitrary libraries to benefit from such a generic protocol.The challenge here is to expose the relevant data about con-cepts and their relation to library methods to the interpreterso that it can be communicated to the debugger. Especiallyin dynamic languages, it needs to be able to expose thisinformation at runtime.Further work is also required to make the visualizationscalable to large applications. We need to find ways to ex-plore complex systems and focus on relevant details, and weneed to investigate ways to provide the relevant data effi-ciently. Future work also needs to study how to effectivelyexpose the large number of concurrency-specific debuggerfeatures to users, and whether they help to debug concurrentapplications more effectively.
Acknowledgments
We would like to thank Sander Lenaerts for the implementa-tion of the actor turn view, and Manuel Rigger and RichardRoberts for comments on an early draft. Stefan Marr andDominik Aumayr were funded by a grant of the AustrianScience Fund (FWF), project number I2491-N31. Carmen Tor-res Lopez was funded by a grant of the Research FoundationFlanders (FWO), project number G004816N.
References
George S. Almasi and Allan Gottlieb. 1994.
Highly Parallel Computing (2nded.). Benjamin-Cummings Publishing Co., Inc.Robert D. Blumofe, Christopher F. Joerg, Bradley C. Kuszmaul, Charles E.Leiserson, Keith H. Randall, and Yuli Zhou. 1995. Cilk: An EfficientMultithreaded Runtime System. In
Proc. of PPoPP , Vol. 30. ACM.Gilad Bracha, Peter von der Ahé, Vassili Bykov, Yaron Kashai, WilliamMaddox, and Eliot Miranda. 2010. Modules as Objects in Newspeak. In
Proc. of ECOOP . LNCS, Vol. 6183. Springer, 405–428.Andrei Chiş, Marcus Denker, Tudor Gîrba, and Oscar Nierstrasz. 2015. Practi-cal domain-specific debuggers using the Moldable Debugger framework.
Computer Languages, Systems & Structures
44, Part A (2015), 89–113.Joeri De Koster, Tom Van Cutsem, and Wolfgang De Meuter. 2016. 43 Yearsof Actors: A Taxonomy of Actor Models and Their Key Properties. In
Proc. of AGERE!’16 . ACM, 31–40.Elisa Gonzalez Boix, Carlos Noguera, and Wolfgang De Meuter. 2014. Dis-tributed debugging for mobile networks.
Systems and Software
90 (2014).Tim Harris, Simon Marlow, Simon Peyton-Jones, and Maurice Herlihy. 2005.Composable Memory Transactions. In
Proc. of PPoPP’05 . ACM, 48–60.C. A. R. Hoare. 1978. Communicating Sequential Processes.
Commun. ACM
21, 8 (1978), 666–677.Sven Keidel, Wulf Pfeiffer, and Sebastian Erdweg. 2016. The IDE PortabilityProblem and Its Solution in Monto. In
Proc. of SLE’16 . ACM, 152–162.Leslie Lamport. 1978. Time, Clocks, and the Ordering of Events in a Dis-tributed System.
Commun. ACM
21, 7 (July 1978), 558–565.Stefan Marr, Carmen Torres Lopez, Dominik Aumayr, Elisa Gonzalez Boix,and Hanspeter Mössenböck. 2017. Kómpos: A Platform for DebuggingComplex Concurrent Applications. (2 April 2017), 2 pages.Charles E. McDowell and David P. Helmbold. 1989. Debugging ConcurrentPrograms.
ACM Comput. Surv.
21, 4 (Dec. 1989), 593–622.Mark S. Miller, E. Dean Tribble, and Jonathan Shapiro. 2005. ConcurrencyAmong Strangers: Programming in E as Plan Coordination. In
Symposiumon Trustworthy Global Computing (LNCS) , R. De Nicola and D. Sangiorgi(Eds.), Vol. 3705. Springer, 195–229.Jorge Ressia, Alexandre Bergel, and Oscar Nierstrasz. 2012. Object-CentricDebugging. In
Proceedings of the 34th International Conference on SoftwareEngineering (ICSE ’12) . IEEE Press, 485–495.Chris Seaton, Michael L. Van De Vanter, and Michael Haupt. 2014. Debug-ging at Full Speed. In
Proc. of DYLA’14 . ACM, Article 2, 13 pages.Terry Stanley, Tyler Close, and Mark Miller. 2009.
Causeway: A message-oriented distributed debugger . Technical Report. HP Labs. 1–15 pages.HP Labs tech report HPL-2009-78.Samira Tasharofi, Peter Dinges, and Ralph E. Johnson. 2013. Why Do ScalaDevelopers Mix the Actor Model with other Concurrency Models?. In
Proc. of ECOOP (LNCS) , Vol. 7920. Springer, 302–326.Carmen Torres Lopez, Stefan Marr, Hanspeter Mössenböck, and Elisa Gon-zalez Boix. 2016. Towards Advanced Debugging Support for ActorLanguages: Studying Concurrency Bugs in Actor-based Programs. (30October 2016). Presentation, AGERE! ’16.Tom Van Cutsem, Elisa Gonzalez Boix, Christophe Scholliers, Andoni Lom-bide Carreton, Dries Harnie, Kevin Pinte, and Wolfgang De Meuter. 2014.AmbientTalk: programming responsive mobile peer-to-peer applicationswith actors.
Com. Lan., Sys. & Struct.
40, 3–4 (2014), 112–136.Michael Van De Vanter. 2017. Building Flexible, Low-Overhead ToolingSupport into a High-Performance Polyglot VM: Extended Abstract. (2April 2017), 3 pages. Presentation, MoreVMs’17.Michael L. Van De Vanter. 2015. Building Debuggers and Other Tools: WeCan "Have It All". In
Proc. of ICOOOLPS’15 . ACM, Article 2, 3 pages.Thomas Würthinger, Andreas Wöß, Lukas Stadler, Gilles Duboscq, DougSimon, and Christian Wimmer. 2012. Self-Optimizing AST Interpreters.In
Proc. of DLS’12 . 73–82.Ferad Zyulkyarov, Tim Harris, Osman S. Unsal, Adrían Cristal, and Ma-teo Valero. 2010. Debugging Programs That Use Atomic Blocks andTransactional Memory. In