Tardis

Barr, Earl T.; Marron, Mark

doi:10.1145/2660193.2660209

Cited by 19 publications

(16 citation statements)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Relational query optimization is a prime realistic example. 3 In our setting, we can revisit it, with Datalog syntax, before building further on it. A common static analysis rule, responsible for interpreting calls as assignments from actual to formal arguments, is shown below:…”

Section: Programming Model: Costmentioning

confidence: 99%

“…This complicates debugging enormously. For instance, the mechanism of time-travel debugging (e.g., see Reference [3]), which has captured the programming community's imagination in recent years, works only when the space of intermediate values of a computation is not that much larger from the space of final values. This is not the case for abstract programs.…”

Section: Changes To Development Workflowsmentioning

confidence: 99%

See 1 more Smart Citation

Next-paradigm programming languages: what will they look like and what changes will they bring?

Smaragdakis

2019

Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

View full text Add to dashboard Cite

The dream of programming language design is to bring about orders-of-magnitude productivity improvements in software development tasks. Designers can endlessly debate on how this dream can be realized and on how close we are to its realization. Instead, I would like to focus on a question with an answer that can be, surprisingly, clearer: what will be the common principles behind next-paradigm, high-productivity programming languages, and how will they change everyday program development? Based on my decade-plus experience of heavy-duty development in declarative languages, I speculate that certain tenets of highproductivity languages are inevitable. These include, for instance, enormous variations in performance (including automatic transformations that change the asymptotic complexity of algorithms); a radical change in a programmer's workflow, elevating testing from a near-menial task to an act of deep understanding; a change in the need for formal proofs; and more.[W]e've passed the point of diminishing returns. No future language will give us the factor of 10 advantage that assembler gave us over binary. No future language will give us 50%, or 20%, or even 10% reduction in workload.Robert C. Martin [17]

show abstract

Section: Programming Model: Costmentioning

confidence: 99%

Section: Changes To Development Workflowsmentioning

confidence: 99%

Next-paradigm programming languages: what will they look like and what changes will they bring?

Smaragdakis

2019

Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

View full text Add to dashboard Cite

show abstract

“…A recent example is the work of Barr and Marron [53] on the TARDIS debugger which provides very efficient omniscient debugging for C#. While most research on omniscient debugging is being done for GPLs, little work has been done to provide omniscient debugging for executable DSLs.…”

Section: Omniscient Debugging For Executable Dslsmentioning

confidence: 99%

Omniscient debugging for executable DSLs

Bousse

LeRoy²,

Combemale

et al. 2018

Journal of Systems and Software

View full text Add to dashboard Cite

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.

show abstract

“…These images allow developers to deploy a pre-configured system into production or continue development at a previous state. Snapshots can also facilitate time-traveling and record & replay debugging [4,5], by restoring a program execution to an earlier point in time to investigate events that lead to the occurrence of a bug. Finally, snapshots enable quick crash recovery and moving a program's execution to a different machine.…”

Section: Introductionmentioning

confidence: 99%

“…Creating a snapshot requires the program state to be persisted. In Lisp, Smalltalk, and other systems [4], this is done with heap dumps integrated with the garbage collector (GC). This, however, requires virtual machine (VM) support and usually stops the world to create a consistent snapshot, making the program unresponsive.…”

Section: Introductionmentioning

confidence: 99%

Asynchronous snapshots of actor systems for latency-sensitive applications

Aumayr¹,

Marr

Boix

et al. 2019

Proceedings of the 16th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes

View full text Add to dashboard Cite

The actor model is popular for many types of server applications. Efficient snapshotting of applications is crucial in the deployment of pre-initialized applications or moving running applications to different machines, e.g for debugging purposes. A key issue is that snapshotting blocks all other operations. In modern latency-sensitive applications, stopping the application to persist its state needs to be avoided, because users may not tolerate the increased request latency.In order to minimize the impact of snapshotting on request latency, our approach persists the application's state asynchronously by capturing partial heaps, completing snapshots step by step. Additionally, our solution is transparent and supports arbitrary object graphs.We prototyped our snapshotting approach on top of the Truffle/Graal platform and evaluated it with the Savina benchmarks and the Acme Air microservice application. When performing a snapshot every thousand Acme Air requests, the number of slow requests ( 0.007% of all requests) with latency above 100ms increases by 5.43%. Our Savina microbenchmark results detail how different utilization patterns impact snapshotting cost.To the best of our knowledge, this is the first system that enables asynchronous snapshotting of actor applications, i.e. without stop-the-world synchronization, and thereby minimizes the impact on latency. We thus believe it enables new deployment and debugging options for actor systems.CCS Concepts • Software and its engineering → Software testing and debugging; • Theory of computation → Concurrency.

show abstract

Tardis

Cited by 19 publications

References 40 publications

Next-paradigm programming languages: what will they look like and what changes will they bring?

Next-paradigm programming languages: what will they look like and what changes will they bring?

Omniscient debugging for executable DSLs

Asynchronous snapshots of actor systems for latency-sensitive applications

Contact Info

Product

Resources

About