DOCSLIB.ORG

Improving Programming Support for Hardware Accelerators Through Automata Processing Abstractions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Improving Programming Support for Hardware Accelerators Through Automata Processing Abstractions Improving Programming Support for Hardware Accelerators Through Automata Processing Abstractions by Kevin A. Angstadt A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Science and Engineering) in the University of Michigan 2020 Doctoral Committee: Professor Westley Weimer, Chair Assistant Professor Reetuparna Das Assistant Professor Jean-Baptiste Jeannin Professor Kevin Skadron, University of Virginia If you find that you’re spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you’re spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice. — Donald Knuth Ein neues Tor ins Unglaubliche und ins Mögliche, ein neuer Tag, an dem alles geschehen konnte, wenn man es nur wollte. — Tove Jansson, Muminvaters wildbewegte Jugend Kevin A. Angstadt [email protected] ORCID iD: 0000-0002-0104-5257 c Kevin A. Angstadt 2020 acknowledgments Research is an inherently collaborative endeavor, and throughout this long jour- ney, I have been supported by some phenomenal individuals. I would like to acknowledge, with brevity unbefitting of their contributions, many of those who helped me reach this moment in my life. First, I would like to thank my advisor, Westley Weimer, who has patiently guided me through my journey of doctoral studies from start to finish. Wes con- tinually challenged me to step outside my academic comfort zone while helping me learn the skills necessary to be a successful researcher. Wes’s knowledge of program analysis techniques played a key role in the success of the work described in this dissertation. I may have needed to take graduate-level Programming Lan- guages two and a half times, but I got there eventually. I am also seriously indebted to Wes’s efforts to support my mentorship and teaching interests. I would not be the educator and scholar I am today without Wes. Finally, I must thank Wes for always being a good sport when it comes to terrible puns—even in our most overworked hours testing and implementing quadcopter-based software systems. Next, I would like to thank Kevin Skadron, my former advisor and continued mentor. Kevin is the reason this dissertation exists; he got me hooked during a visit to the University of Virginia when he described a new project involving an ii experimental processor. Little did I know that it would be the start of a six-year journey into understanding how to best leverage finite automata to program new kinds of hardware! I am also thankful for Kevin’s ability to always consider the “big picture” and to remind me of its importance. None of this work would be possible without the expertise and experience of my collaborators. Thank you to Jack Wadden, Tommy Tracy II, Matt Casias, Arun Subramaniyan, Xiaowei Wang, Elaheh Sadredini, Reza Rahimi, Vinh Dang, Ted Xie, Nathan Brunelle, Chunkun Bo, Dan Kramp, Reetuparna Das, Stephanie Forrest, Jean-Baptise Jeannin, Mircea Stan, and Lu Feng for all that they have taught me while we conducted research together. To my computer architecture colleagues, thank you for your patience whenever I would ask ignorant questions. To my software engineering and programming languages colleagues, thank you for your patience whenever I would ask ignorant questions. I am also very much appreciative of my officemates over the years: Jonathan Dorn, Kevin Leach, Yu Huang, Madeline Endres, Colton Holoday, Zohreh Sharafi, Jamie Floyd, Kate Highnam, Hammad Ahmad, Fee Christoph, Yirui Liu, Ryan Krueger, Xinyu Liu, and Martin Kellogg. I truly enjoyed our conversations over the years and their willingness to teach me about their research. I also wish to acknowledge my teaching colleagues and mentors. While teaching is not an explicit part of the doctoral experience, it was a significant portion of my experience. Teaching is what has kept me motivated to finish. I am indebted to Amir Kamil, Dave Paoletti, Marcus Darden, Mark Sherriff, Luther Tychonievich, iii Ed Harcourt, and Patti Frazer Lock (among others) for all that they have done to help my development as an educator over the years. I would not have been able to complete this degree without the unconditional love and support of my family (Mom, Dad, Mike, Charlotte, Linnea, Shay, my grandparents, and my aunts and uncles). I might not have always been able to communicate clearly to them what my research is about, but they’ve stuck by me nonetheless. I’m fortunate to be able to celebrate my successes and overcome my setbacks with them by my side. To my family: thank you, and I love you. Thank you to my friends (Katja, Elaine, Nya, Terry, Liz, Joey, Tristan, Erin, Samyukta, Christabel, and Clara, among others) for tolerating my quirkiness. They have made this six-year journey significantly more fun and tolerable. Finally, thank you to you, the reader. The fact that you are reading this now means that my efforts were not for naught. If I have forgotten to thank you, I apologize. It has more to do with fatigue than anything else. iv table of contents acknowledgments ii list of figures xiii list of tables xv list of source code listings xvii list of algorithms xvii list of acronyms xviii abstract xxiv chapter 1introduction 1 1.1 Approach . 3 1.2 Contributions . 5 1.2.1 Adapting Legacy Code for Execution on Hardware Acceler- ators . 5 v 1.2.2 High-Level Languages for Automata Processing . 6 1.2.3 Interactive Debugging for High-Level Languages and Accel- erators . 7 1.2.4 Architectural Support for Common Applications . 8 1.3 Methodology . 10 1.4 Summary and Organization . 11 2 background 13 2.1 Finite Automata . 13 2.1.1 Deterministic and Non-Deterministic Finite Automata . 14 2.1.2 Deterministic Pushdown Automata . 16 2.2 Accelerating Automata Processing . 19 2.2.1 Micron’s D480 AP......................... 21 2.2.2 Cache Automaton . 23 2.2.3 Field-Programmable Gate Arrays . 24 2.3 Programming Models . 26 2.3.1 Automata Representations and Regular Expressions . 26 2.3.2 Languages for Streaming Applications . 28 2.3.3 Non-Deterministic Languages . 29 2.3.4 Programming Models for Portability . 30 2.3.5 Languages for Programming FPGAs . 31 2.3.6 State Machine Learning Algorithms . 33 2.3.7 Program Synthesis . 34 2.4 Maintenance Tools . 35 vi 2.4.1 Debugging on Hardware Accelerators . 35 2.4.2 Understanding the Importance of Debugging . 36 2.4.3 Software Verification . 37 2.5 Applications Benefiting from Acceleration . 38 2.5.1 Parsing of XML Files . 38 2.5.2 Architectural Side-Channel Attacks . 40 2.5.3 Runtime Intrusion Detection Systems . 42 2.6 Chapter Summary . 43 3 accelerationoflegacystringfunctions 44 3.1 Learning State Machines from Legacy Code . 47 3.1.1 L* Primer . 47 3.1.2 AutomataSynth Problem Description . 49 3.1.3 Using Source Code as a MAT . 51 3.1.4 Synthesizing Hardware Descriptions from Automata . 54 3.1.5 System Architecture . 54 3.2 Implementation and Correctness . 56 3.2.1 Bounded Model Checking . 56 3.2.2 Reasoning about Strings . 57 3.2.3 Verification for Termination Queries . 58 3.2.4 Correctness . 60 3.2.5 Implications. 65 3.3 Experimental Methodology . 66 3.3.1 Benchmark Selection . 66 vii 3.3.2 Experimental Setup . 68 3.4 Evaluation . 70 3.4.1 State Machine Learning . 70 3.4.2 Hardware Acceleration . 72 3.5 Discussion . 73 3.5.1 Learning More Expressive Models . 74 3.5.2 Expressive Power and Performance of String Solvers . 75 3.5.3 Scaling Termination Queries . 76 3.5.4 Characterizing and Taming Approximation . 77 3.6 Chapter Summary . 78 4 rapid: a high-level language for portable automata pro- cessing 80 4.1 Automata Processing Stability . 83 4.1.1 Performance Stability . 83 4.1.2 Automata Processing Performance . 86 4.1.3 Discussion . 89 4.2 The RAPID Language . 90 4.2.1 Program Structure . 91 4.2.2 Types and Data in RAPID . 94 4.2.3 Parallel Control Structures . 96 4.3 Code Generation . 100 4.3.1 Converting Expressions . 101 4.3.2 Converting Statements . 103 viii 4.3.3 Converting Counters . 104 4.4 Executing RAPID Programs . 108 4.4.1 Targeting the Automata Processor . 109 4.4.2 Targeting CPUs . 109 4.4.3 Targeting GPUs . 111 4.4.4 Targeting FPGAs . 111 4.5 Evaluation . 112 4.5.1 Expressive Power . 113 4.5.2 Empirical Evaluation . 115 4.6 Chapter Summary . 121 5 interactive debugging for high-level languages and ac- celerators 123 5.1 Hardware-Supported Debugging . 127 5.1.1 Example Program . 127 5.1.2 Breakpoints . 129 5.1.3 Hardware Abstractions for Debugging . 130 5.1.4 Accessing the State Vector . 131 5.1.5 Hardware Support for Breakpoints . 134 5.1.6 Debugging of RAPID Programs . 137 5.1.7 Time-Travel Debugging . 138 5.2 FPGA Evaluation . 139 5.2.1 Experimental Methodology . 140 5.2.2 FPGA Results . 142 ix 5.3 Human Study Evaluation . 145 5.3.1 Experimental Methodology . 145 5.3.2 Statistical Analysis . 147 5.3.3 Threats to Validity . 150 5.4 Chapter Summary . 151 6 architectural support for automata-based computation 153 6.1 Detecting Attacks with Memory Accesses . 158 6.1.1 The Memory Access Pattern Abstraction . 159 6.1.2 Dictionaries of Program Behavior . 162 6.1.2.1 D-Windows . 163 6.1.2.2 Truncation . 163 6.1.2.3 Compression . 164 6.1.3 Detecting Anomalous Program Execution . 165 6.2 Compiling Grammars to Pushdown Automata .
Load more

Recommended publications
  • TARDIS: Affordable Time-Travel Debugging in Managed Runtimes
    TARDIS: Affordable Time-Travel Debugging in Managed Runtimes Earl T. Barr Mark Marron University College London Microsoft Research [email protected] [email protected] Abstract 1. Introduction Developers who set a breakpoint a few statements too late or Developers spend a great deal of time debugging. Skilled de- who are trying to diagnose a subtle bug from a single core velopers apply the scientific method: they observe a buggy dump often wish for a time-traveling debugger. The ability program’s behavior on different inputs, first to reproduce the to rewind time to see the exact sequence of statements and bug, then to localize the bug in the program’s source. Re- program values leading to an error has great intuitive appeal producing, localizing, then fixing a bug involves forming but, due to large time and space overheads, time-traveling and validating hypotheses about the bug’s root cause, the debuggers have seen limited adoption. first point at which the program’s state diverges from the in- A managed runtime, such as the Java JVM or a JavaScript tended state. To validate a hypothesis, a developer must halt engine, has already paid much of the cost of providing core program execution and examine its state. Especially early in features — type safety, memory management, and virtual debugging, when the developer’s quarry is still elusive, she IO — that can be reused to implement a low overhead time- will often halt execution too soon or too late to validate her traveling debugger. We leverage this insight to design and current hypothesis.
    [Show full text]
  • Sindarin: a Versatile Scripting API for the Pharo Debugger
    Sindarin: A Versatile Scripting API for the Pharo Debugger Thomas Dupriez Guillermo Polito Steven Costiou Univ. Lille, CNRS, Centrale Lille, CNRS - UMR 9189 - CRIStAL, Univ. Inria, Univ. Lille, CNRS, Centrale Inria, UMR 9189 - CRIStAL Lille, Centrale Lille, Inria Lille, UMR 9189 - CRIStAL France France France [email protected] [email protected] [email protected] Vincent Aranega Stéphane Ducasse Univ. Lille, CNRS, Centrale Lille, Inria, Univ. Lille, CNRS, Centrale Inria, UMR 9189 - CRIStAL Lille, UMR 9189 - CRIStAL France France [email protected] [email protected] Abstract Studies and work on debugging acknowledge that main- Debugging is one of the most important and time consuming stream debuggers are not well adapted to several debugging activities in software maintenance, yet mainstream debuggers scenarios [3, 27, 31]. This has led to the appearance of new de- are not well-adapted to several debugging scenarios. This bugging techniques proposing to augment traditional interac- has led to the research of new techniques covering specific tive debuggers with, e.g., stateful breakpoints [4], control-flow families of complex bugs. Notably, recent research proposes aware breakpoints [5], object-centric breakpoints [10, 34], the to empower developers with scripting DSLs, plugin-based and automatic insertion of breakpoints based on dynamic execu- moldable debuggers. However, these solutions are tailored to tions [45], or declarative statements from the developer [21]. specific use-cases, or too costly for one-time-use scenarios. A line of research has also started to study scripting APIs to In this paper we argue that exposing a debugging scripting empower developers to implement debugging scripts adapted interface in mainstream debuggers helps in solving many chal- to their needs.
    [Show full text]
  • Deterministic Replay of System's Execution with Multi-Target QEMU
    Deterministic Replay of System’s Execution with Multi-target QEMU Simulator for Dynamic Analysis and Reverse Debugging Pavel Dovgalyuk Institute for System Programming of the Russian Academy of Sciences Moscow, Russia [email protected] I. INTRODUCTION II. RELATED WORK Deterministic replay is a technology that allows capturing Software logging for deterministic replay of the the execution of a running virtual machine for later replay. It execution process for whole system is already implemented is useful for debugging failures that are not easily in VMWare [9] and ExecRecorder [6]. But they support reproduced, capturing execution traces, dynamic analysis of deterministic replay only for 32-bit x86 systems. VMWare the software, and so on. also does not provide any mechanisms for implementing dynamic analysis tools on its base. ExecRecorder is based on The examples of bugs that are hard to reproduce are the slow Bochs simulator and does not support saving replay log following: for using it later. - Non-deterministic bugs, e.g. caused by races of the Time-traveling virtual machine described in [4] also uses different threads or applications. When bug is logging of non-deterministic events and checkpointing recorded, it can be replayed again and again, and virtual machine states for deterministic replay and reverse thus, it is no longer non-deterministic. debugging. But this system supports only Linux on x86 as a - Pseudo non-deterministic bugs, when process of target system. reproducing bugs is not clear. Recorded log can be used instead of the error description reproducing Most of other existing software solutions support process. deterministic replay of a single application, not a whole - Bugs that occur with complex environment.
    [Show full text]
  • Time-Travel Debugging Java Applications
    Time-Travel Debugging Java applications Greg Law, co-founder Debugging - our dirty secret Programming is debugging Most software is not truly understood by anyone What happened? printf, printf, printf Why can’t the computer just tell us? 2 3 In the beginning Sir Maurice Wilkes, 1913-2010 In the beginning I well remember [...] the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs Sir Maurice Wilkes, 1913-2010 Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? Brian Kernighan Computers are hard What happened? What makes bugs really hard? Repeatability Time between the root cause and effect being noticed What happened?was the previous state? Two options: 1. Save it. 2. Recompute it. a = a + 1 ✓ a = b ✗ Snapshots Maintain snapshots through history Resume from these - run forward as needed Copy-on-Write for memory efficiency Adjust spacing to anticipate user’s needs Event log Event Log captures non-deterministic state Recorded during debug (or Live Recording) Stored in memory Replayed to reconstruct any point in history Efficient, diff-based representation Saved to create a recording file for later use Instrumentation Undo Engine captures all non-determinism Some machine instructions are non-deterministic rdtsc, cpuid, syscall, etc Needs to capture all this and provide precise control over execution in general Solution: Runtime instrumentation Works well in conjunction with live logging & tracing Logging & tracing give a high-level ‘story’ of a program’s execution Use it to know where to go in a recording Apply logging to a recording 80/20 Rule 80/20 Rule Multiple implementations For Linux: ● Undo LiveRecorder (C++, Go, Java) ● rr (C++, Go) ● gdb process record For Windows: ● Microsoft’s Time-Travel Debugger (C++, C#, Chakracore JS) ● RevDebug (C#, Java) Cross platform ● Chronon debugger ● Omniscient debugger 1.
    [Show full text]
  • Refinement Types for Elm
    Submitted by Lucas Payr K01556372 Submitted at Research Institute for Symbolic Computation Supervisor A.Univ.-Prof. DI Dr. Wolfgang Schreiner April 2021 REFINEMENT TYPES FOR ELM Master Thesis to obtain the academic degree of Diplom-Ingenieur in the Master’s Program Computer Mathematics JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, Österreich www.jku.at DVR 0093696 Zusammenfassung Das Ziel dieser Arbeit ist es, das Typsystem von Elm um sogenannte “Refinement” Typen zu erweitern. Elm ist eine rein funktionale Programmiersprache, welche das Hindley-Miler Typsystem benutzt. Refinement Typen sind eine Form von Subtypen, welche anhand eines Prädikats ihre enthaltenen Werte bestimmen. Eine solche Klasse von Refinement Typen, welche für Hindely-Miler Typsysteme ausgelegt ist, sind die sogenannten “Liquid” Typen. Für sie existiert ein Algorithmus, um für einen Ausdruck den dazugehörigen Typ herzuleiten. Dieser Algorithmus interagiert mit einem SMT Solver, um bestimmte Bedingungen für die Subtypen zu erfüllen. Typsysteme, welche mit Liquid Typen erweitert werden, sind nicht länger vollständig, d.h. sie können nur für bestimmte Ausdrücke hergeleitet werden. Die Prädikate sind ebenfalls restringiert. Diese Arbeit liefert eine formale Definition von Elm und dessen Typsystem, auf deren Basis das System mit Liquid Typen erweitert wird. Hierfür wird eine Teilmenge der Ausdrücke sowie eine Teilmenge der Prädikate präsentiert, um die Wohldefiniertheit der Liquid Typen zu gewährleisten. Zum Überprüfen unserer Ergebnisse benützen wir das freie Softwaresystem “K Framework” sowie eine Implementierung in Elm des Algorithmus zum Lösen der Bedingungen für Subtypen. Als SMT Solver benutzen wir Microsofts Software Z3. 2 Abstract The aim of this thesis is to add refinement types to Elm.
    [Show full text]
  • CROCHET: Checkpoint and Rollback Via Lightweight Heap Traversal on Stock Jvms
    CROCHET: Checkpoint and Rollback via Lightweight Heap Traversal on Stock JVMs Jonathan Bell George Mason University, Fairfax, VA, USA [email protected] 0000-0002-1187-9298 Luís Pina George Mason University, Fairfax, VA, USA [email protected] 0000-0003-4585-5259 Abstract Checkpoint/rollback (CR) mechanisms create snapshots of the state of a running application, allowing it to later be restored to that checkpointed snapshot. Support for checkpoint/rollback enables many program analyses and software engineering techniques, including test generation, fault tolerance, and speculative execution. Fully automatic CR support is built into some modern operating systems. However, such systems perform checkpoints at the coarse granularity of whole pages of virtual memory, which imposes relatively high overhead to incrementally capture the changing state of a process, and makes it difficult for applications to checkpoint only some logical portions of their state. CR sys- tems implemented at the application level and with a finer granularity typically require complex developer support to identify: (1) where checkpoints can take place, and (2) which program state needs to be copied. A popular compromise is to implement CR support in managed runtime environments, e.g., the Java Virtual Machine (JVM), but this typically requires specialized, non- standard runtime environments, limiting portability and adoption of this approach. In this paper, we present a novel approach for Checkpoint ROllbaCk via lightweight HEap Traversal (Crochet), which enables fully automatic fine-grained lightweight checkpoints within unmodified commodity JVMs (specifically Oracle’s HotSpot and OpenJDK). Leveraging key in- sights about the internal design common to modern JVMs, Crochet works entirely through bytecode rewriting and standard debug APIs, utilizing special proxy objects to perform a lazy heap traversal that starts at the root references and traverses the heap as objects are accessed, copying or restoring state as needed and removing each proxy immediately after it is used.
    [Show full text]
  • PROGRAMME HEADLINE 2021 SPONSOR CONFERENCE Bloomberg Is the Leading Provider of Financial News and Information
    EVENT VIRTUAL Spring ACCU 2021.3.10–13 Pre-Conference tutorials 2021.3.9 2021 CONFERENCE PROGRAMME HEADLINE 2021 SPONSOR CONFERENCE Bloomberg is the leading provider of financial news and information. Our R&Ddepartment consists of 3000 engineers working across WELCOME teams in both London and New York. Terminal is the primary product we are known We are technology people – when we write for – it used to run on custom hardware, but code, we like to understand exactly what the is now a piece of software that runs on a PC – hardware is doing. We live and breathe C++, typically connected to 2 or more monitors. Over and are concerned about cpu performance, 315,000 customers pay a monthly subscription optimizations, memory allocation behaviour, to access our real-time data and news, deep Welcome to ACCU 2021! as well as higher-level software engineering analytic functions and trading functionality principles such as building modular, scalable, through our custom browser. You will see many ACCU Conference is the annual conference developers. Even though the conference in reliable and debuggable code. We write a Bloomberg Terminals on most trading floors of the ACCU membership club, but open 2020 had to be cancelled because of the lot of systems ourselves, but have embraced around the world, and in the offices of influential to any and all who wish to attend. The COVID-19 pandemic, many speakers are the open source community. The Bloomberg decision-makers within financial markets. ACCU Conference has a history founded in happy to give their presentations in 2021. studying and evolving C and C++ – many of So we have our usual mix of keynotes, its members continue to have active roles sessions, quickies and lightning talks.
    [Show full text]
  • EXPOSITOR: Scriptable Time-Travel Debugging with First-Class Traces Khoo Yit Phang, Jeffrey S
    1 EXPOSITOR: Scriptable Time-Travel Debugging with First-Class Traces Khoo Yit Phang, Jeffrey S. Foster, and Michael Hicks Computer Science Department, University of Maryland, College Park, MD 20742, USA {khooyp,jfoster,mwh}@cs.umd.edu Abstract—We present EXPOSITOR, a new debugging environment that combines scripting and time-travel debugging to allow programmers to automate complex debugging tasks. The fundamental abstraction provided by EXPOSITOR is the execution trace, which is a time-indexed sequence of program state snapshots or projections thereof. Programmers can manipulate traces as if they were simple lists with operations such as map and filter. Under the hood, EXPOSITOR efficiently implements traces as lazy, sparse interval trees whose contents are materialized on demand. EXPOSITOR also provides a novel data structure, the edit hash array mapped trie, which is a lazy implementation of sets, maps, multisets, and multimaps that enables programmers to maximize the efficiency of their debugging scripts. In our micro-benchmarks, EXPOSITOR scripts are faster than the equivalent non-lazy scripts for common debugging scenarios. We have also used EXPOSITOR to debug a stack overflow, and to unravel a subtle data race in Firefox. We believe that EXPOSITOR represents an important step forward in improving the technology for diagnosing complex, hard-to-understand bugs. Index Terms—debugging, time-travel, scripting, lazy data structures, EditHAMT ✦ 1 INTRODUCTION Scriptable debugging is a powerful technique for hy- “...we talk a lot about finding bugs, but really, [Firefox’s] pothesis testing in which programmers write scripts to bottleneck is not finding bugs but fixing [them]...” perform complex debugging tasks.
    [Show full text]
  • Towards Liveness in Game Development
    Towards Liveness in Game Development Andrew R Martin1 and Simon Colton1;2 1Game AI Research Group, Queen Mary University of London, UK 2 SensiLab, Faculty of IT, Monash University, Australia [email protected] Abstract—In general, videogame development is a difficult which could go on indefinitely. In contrast, it would be trivial and specialist activity. We believe that providing an immediate to hit the same target using a water hose, simply by moving feedback cycle (liveness) in the software used to develop games the hose until the water hits it. In 2012, Bret Victor gave a may enable greater productivity, creativity and enjoyment for both professional and amateur creators. presentation entitled Inventing on Principle [2], in which he There are many different methods for achieving interactivity advocated for tools which provide an immediate connection and immediate feedback in software development, including between creators and the things they create. This presentation read-eval-print loops, edit-and-continue debuggers and dataflow included a highly influential demonstration of a game devel- programming environments. These approaches have each found opment tool, portrayed in figure 1. The presentation inspired success in domains they are well-suited to, but games are particularly challenging due to their interactivity and strict many research projects in academia and industry, such as Ap- performance requirements. We discuss here the applicability of ple’s Swift Playgrounds (apple.com/uk/swift/playgrounds) and some of these ideas to game development, and then outline a Chris Granger’s Light Table (chris-granger.com/lighttable), proposal for a live programming model suited to the unique which crowdfunded investment from more than 7,000 backers.
    [Show full text]
  • A Time-Travel Debugger for Web Audio Applications
    A Time-Travel Debugger for Web Audio Applications ABSTRACT Developing real-time audio applications, particularly Developing real-time audio applications, particularly those those with an element of user interaction, can be a challeng- with an element of user interaction, can be a challenging ing task. When things go wrong, it can be difficult to locate task. When things go wrong, it can be difficult to locate the the source of a problem when many parts of the program are source of a problem when many parts of the program are connected and interacting with one another in real-time. connected and interacting with one another in real-time. A traditional debugger allows the programmer to mark a We present a time-travel debugger for the Flow Web Au- breakpoint that pauses program execution and inspect the dio framework that allows developers to record a session program state. The programmer can insert multiple break- interacting with their program, playback that session with points and step forward to the next one by running the pro- the original timing still intact, and step through individual gram up until that point. Reverse debugging builds on this events to inspect the program state any point in time. In idea by allowing the programmer to step backwards from contrast to the browser's native debugging features, audio a breakpoint to uncover the cause of an error. Time-travel processing remains active while the time-travel debugger is debugging provides both of these capabilities, allowing the enabled; allowing developers to listen out for audio bugs or programmer to step both forwards and backwards in time.
    [Show full text]
  • Righting Web Development
    University of Massachusetts Amherst ScholarWorks@UMass Amherst Doctoral Dissertations Dissertations and Theses October 2018 Righting Web Development John Vilk University of Massachusetts Amherst Follow this and additional works at: https://scholarworks.umass.edu/dissertations_2 Part of the OS and Networks Commons, and the Programming Languages and Compilers Commons Recommended Citation Vilk, John, "Righting Web Development" (2018). Doctoral Dissertations. 1405. https://doi.org/10.7275/12765546 https://scholarworks.umass.edu/dissertations_2/1405 This Open Access Dissertation is brought to you for free and open access by the Dissertations and Theses at ScholarWorks@UMass Amherst. It has been accepted for inclusion in Doctoral Dissertations by an authorized administrator of ScholarWorks@UMass Amherst. For more information, please contact [email protected]. RIGHTING WEB DEVELOPMENT A Dissertation Presented by JOHN VILK Submitted to the Graduate School of the University of Massachusetts Amherst in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY September 2018 College of Information and Computer Sciences c Copyright by John Vilk 2018 All Rights Reserved RIGHTING WEB DEVELOPMENT A Dissertation Presented by JOHN VILK Approved as to style and content by: Emery D. Berger, Chair Yuriy Brun, Member Arjun Guha, Member David Irwin, Member James Mickens, Member James Allan, Chair of Faculty College of Information and Computer Sciences DEDICATION For my mother, who has always believed in me and pushed me to do my best. ACKNOWLEDGMENTS First, I would like to thank my advisor, Emery Berger, for his unwavering support and invaluable guidance over the past seven years. Your advice has had a considerable impact on how I conduct research, present ideas, and measure success.
    [Show full text]
  • TARDIS: Affordable Time-Travel Debugging in Managed Runtimes
    TARDIS: Affordable Time-Travel Debugging in Managed Runtimes Earl T. Barr Mark Marron University College London Microsoft Research [email protected] [email protected] Abstract 1. Introduction Developers who set a breakpoint a few statements too late or Developers spend a great deal of time debugging. Skilled de- who are trying to diagnose a subtle bug from a single core velopers apply the scientific method: they observe a buggy dump often wish for a time-traveling debugger. The ability program’s behavior on different inputs, first to reproduce the to rewind time to see the exact sequence of statements and bug, then to localize the bug in the program’s source. Re- program values leading to an error has great intuitive appeal producing, localizing, then fixing a bug involves forming but, due to large time and space overheads, time-traveling and validating hypotheses about the bug’s root cause, the debuggers have seen limited adoption. first point at which the program’s state diverges from the in- A managed runtime, such as the Java JVM or a JavaScript tended state. To validate a hypothesis, a developer must halt engine, has already paid much of the cost of providing core program execution and examine its state. Especially early in features — type safety, memory management, and virtual debugging, when the developer’s quarry is still elusive, she IO — that can be reused to implement a low overhead time- will often halt execution too soon or too late to validate her traveling debugger. We leverage this insight to design and current hypothesis.
    [Show full text]