Omniscient debugging for executable DSLs

Abstract

Omniscient debugging is a promising technique that relies on execution traces to enable free traversal of the states reached by a model (or program) during an execution. While a few General-Purpose Languages (GPLs) already have support for omniscient debugging, developing such a complex tool for any executable Domain Specific Language (DSL) remains a challenging and error prone task. A generic solution must: support a wide range of executable DSLs independently of the metaprogramming approaches used for implementing their semantics; be efficient for good responsiveness. Our contribution relies on a generic omniscient debugger supported by efficient generic trace management facilities. To support a wide range of executable DSLs, the debugger provides a common set of debugging facilities, and is based on a pattern to define runtime services independently of metaprogramming approaches. Results show that our debugger can be used with various executable DSLs implemented with different metaprogramming approaches. As compared to a solution that copies the model at each step, it is on average six times more efficient in memory, and at least 2.2 faster when exploring past execution states, while only slowing down the execution 1.6 times on average.Keywords: Software Language Engineering; Domain-Specific Languages; Executable DSL; Omniscient debugging; Execution trace IntroductionA large amount of Domain-Specific Languages (DSLs) have been proposed and used to describe the dynamic aspects of systems [1,2,3,4,5]. In that context, early dynamic verification and validation (V&V) techniques, such as testing [6], semantic differencing [7] or runtime verification [8], are necessary to ensure that such executable models (or programs 1 ) are correct. These techniques require models to be executable, which can be achieved by defining the * Corresponding author Email addresses: erwan.bousse@tuwien.ac.at (Erwan Bousse), dorian.leroy@jku.at (Dorian Leroy), benoit.combemale@irit.fr (Benoit Combemale), wimmer@big.tuwien.ac.at (Manuel Wimmer), baudry@kth.se (Benoit Baudry)1 We arbitrarily use the term executable model since this work focuses on metamodel-based DSLs, but the term program can be used interchangeably.

Behavioral interfaces for executable DSLs

“…The state of the model is considered observable and alterable at the time notifications are made and handled; hence, the possible observable states reached during an execution are heavily dependent on the granularity of the declared stepping rules in a semantics. This notification mechanism can not only be used to attach interactive debuggers [6] and trace constructors [7] to the execution. We explain later how we leverage this notification mechanism to enable exposed events and run-to-completion call requests.…”

“…We explain later how we leverage this notification mechanism to enable exposed events and run-to-completion call requests. The design of an execution engine is described in more detail in our previous work [5,6] and can be summarized as the following operations:…”

“…In order to make use of the approach, a reflective event injection GUI was designed, allowing to send and receive event occurrences from running models and complementing the existing generic omniscient debugger for xDSLs defined in the language workbench [6]. We detail this tool in the next section.…”

“…As we implemented our approach and tools within the GEMOC Studio, we are able to use the reflective event injection GUI in conjugation with the generic debugger already provided by the GEMOC Studio [6]. Using this extended debugger, we are able to pause the execution, queue event occurrences, use stepping operators (forward and backward), define breakpoints and resume a paused execution to evaluate the impact of queued event occurrences on this execution.…”

Constraint-based run-time state migration for live modeling

“…Beyond classical forward-in-time debuggers, Bousse et al proposed a methodology for the development of generic omniscient debuggers for DSLs [2] backed by efficient and domain-specific execution trace management facilities [3]. Ráth et al use the VIATRA [29] framework to simulate Petri nets.…”