With the widespread use of multicore processors, software becomes more and more diverse in its use of parallel computing resources. To address all application requirements, each with the appropriate abstraction, developers mix and match various concurrency abstractions made available to them via libraries and frameworks. Unfortunately, today's tools such as debuggers and pro lers do not support the diversity of these abstractions. Instead of enabling developers to reason about the high-level programming concepts, they used to express their programs, the tools work only on the library's implementation level. While this is a common problem also for other libraries and frameworks, the complexity of concurrency exacerbates the issue further, and reasoning on the higher levels of the concurrency abstractions is essential to manage the associated complexity. In this position paper, we identify open research issues and propose to build tools based on a common meta-level interface to enable developers to reasons about their programs based on the high-level concepts they used to implement them.
Co
Submission to: 9. Arbeitstagung Programmiersprachen, Vienna, Austria, 25 February 2016 Debugger
Profiler
Race Detection …
DataFlow Fork/Join
… Meta-Level Tooling Interface
Minimal Interference Instrumentation
Language Implementation
of Scala programs [Tasharo
While the use of multiple concurrency models in the same application has been recognized as an issue [Haller,
2015, Swal
To bring tooling to the wide range of concurrency models, we envision a meta-level interface that allows tools
to connect to the language implementation and observe program execution as well as interact with it by using a
common set of basic concepts that underlie a wide range of concurrency abstractions. This idea is reminiscent
to classic metaobject protocols (MOP) [Kiczales et al., 1991], which reify the concepts of a language and its
implementation to enable tooling as well as dynamic adaptation from within a program. This idea can also be
seen in widely used VM tooling interfaces [Wurthin
Figure 1 visualizes the relation of the envisioned meta-level interface with respect to concurrency abstractions, tools, and instrumentation at the level of language implementation. The key for making the interface independent of concrete concurrency abstractions is to identify the fundamental building blocks for each abstraction. For instance for message-passing approaches, the exchange of messages and the involved mailboxes or channels are essential, because they allow developers to reason about the information ow between actors or processes. Shared memory models on the other hand have other basic notions. In an STM, it is relevant to know in which order transactions have been executed, which ones caused transaction aborts or retries. To understand applications with locks, one needs however information on which resources are protected by locks, and how and when the locks are acquired. Declarative concurrency models are again di erent, in that they typically express data dependencies explicitly. 3
For such a meta-level interface, we need to distill the set of basic building blocks instead of merely enumerating all high-level concepts. Thus, one of the challenges is to identify the common core concepts shared between concurrency abstractions so that a wide range of concepts can be represented. However, this is not the only challenge. The next section details the problems that need to be tackled to realize the vision of a common meta-level interface for debugging.
To build high-level debuggers and other tools for the development of complex concurrent systems, we face issues in three areas: how to debug programs that employ multiple concurrency models, how to provide instrumentation for such tooling that minimizes interference with program execution, and how to decouple these mechanisms from concrete concurrency abstractions. We detail these problem brie y in the remainder of this section. 3.1
Prior research has studied debugging support for many of the individual concurrency models. However, debuggers
for programs that employ multiple concurrency models are unexplored. Generally, M
As an approach that is especially relevant in the eld of concurrency, research on breakpoint-based debuggers
led to time-traveling d
However, it remains open how to build a uniform debugger that supports a wide variety of concurrency models. We see this as an open question both from the user perspective and the implementation perspective. Considering typical scenarios, such a debugger needs to be able to help developers to understand their programs from di erent perspectives or levels of granularity. For instance in an actor program, one might want to continue execution until a message is processed completely, or one might want to see which messages caused which e ects to see races or bottlenecks. In a transaction, one might want to complete a whole atomic block, or in a lock-based part of the program continue execution until a lock is taken or released. All these are di erent concepts that have to be carefully represented to be understandable for the user, but must also be realized in a way generic that is enough so that the new en vogue concurrency concept of the day can be supported. 3.2
For debugging, it is also still an open question how to record concurrent executions, while minimizing the
necessary data and instrumentation. Instrumentation of concurrent programs is generally problematic, because
it can interfere with the execution so that data races might never appear with the instrumentation. Thus, it is
essential to minimize general interference. Part of that is to minimize the amount of record
The main goal is, however, to identify techniques that are applicable to a wide range of concurrency models to
be able to represent high-level concepts to developers. Thus, relevant techniques include recording for re
As mentioned in section 2, our goal is to de ne a meta-level interface that can be used to observe and to
interact with the execution of complex concurrent systems that use a wide range of concurrency abstractions.
We envision the use of a meta-level interface based on the insight that tools always have a tight connection to
meta-level programming. Thus, it is natural that programs are either manipulated (statically) or executed and
monitored (dynamically) by a tool, which can also be the program itself. The code of the tool interacts with
the code of the program by means of such a meta-level interface, which is tightly bound to the design of the
programming language. Examples are VM tooling interfaces [Wurthin
For the development of complex concurrent systems, we need better tools! Currently, debugging and tooling is only available on the implementation level and does not capture high-level concepts. With the complexity of concurrent software especially when it mixes and matches di erent abstractions, it is essential to preserve these abstractions also during debugging in order to understand a program's behavior.
We see a meta-level interface that abstracts from concrete concurrency models as a way forward. However, there are many open research questions: starting from how to build debuggers for di erent interacting concurrency abstractions, over the question of how to avoid problematic interference with program execution, as well as how to abstract from concrete concurrency models for such an interface.
Recently, we started to investigate these issues in the context of the Tru e and Graal language implementation
platform [Wurthing
This research is funded by a collaboration grant of the Austrian Science Fund (FWF) with the project I2491-N31 and the Research Foundation Flanders (FWO Belgium).