# Literature 

## Promises

- [The Great Escape from Callback Hell](https://medium.com/@js_tut/the-great-escape-from-callback-hell-3006fa2c82e)

- "Contemporary live debuggers do not display the complete call stack history for concurrent threads. Hence, developers have less information at their disposal when debugging concurrent threads than when debugging a single threaded, sequential program. We solve the problem of incomplete thread history by creating a debugger that operates on a virtual call stack comprised of multiple threads. With live debuggers displaying at least the equivalent information for both single threaded, sequential programs and concurrent threads, developers can focus on the hard parts of concurrency issues." [@Leske2016ILD]

- "Concurrency issues are inherently harder to identify and fix than issues in sequential programs, due to aspects like indeterminate order of access to shared resources and thread synchronisation. Live debuggers are often used by developers to gain insights into the behaviour of concurrent programs by exploring the call stacks of threads. Nevertheless, contemporary live debuggers for concurrent programs are usually sequential debuggers augmented with the ability to display different threads in isolation. To these debuggers every thread call stack begins with a designated start routine and the calls that led to the creation of the thread are not visible, as they are part of a different thread. This requires developers to manually link stack traces belonging to related but distinct threads, adding another burden to the already difficult act of debugging concurrent programs. To improve debugging of concurrent programs we address the problem of incomplete call stacks in debuggers through a thread and debugger model that enables live debugging of child threads within the context of their parent threads. The proposed debugger operates on a virtual thread that merges together multiple relevant threads. To better understand the features of debuggers for concurrent programs we present an in-depth discussion of the concurrency related features in current live debuggers. We test the applicability of the proposed model by instantiating it for simple threads, local and remote promises, and a remote object-oriented database. Starting from these use cases we further discuss implementation details ensuring a practical approach." [@Leske2017ILD]

- "In JavaScript programs, asynchrony arises in situations such as web-based user-interfaces, communicating with servers through HTTP requests, and non-blocking I/O. Event-based programming is the most popular approach for managing asynchrony, but suffers from problems such as lost events and event races, and results in code that is hard to understand and debug. Recently, ECMAScript 6 has added support for promises, an alternative mechanism for managing asynchrony that enables programmers to chain asynchronous computations while supporting proper error handling. However, promises are complex and error-prone in their own right, so programmers would benefit from techniques that can reason about the correctness of promise-based code. Since the ECMAScript 6 specification is informal and intended for implementers of JavaScript engines, it does not provide a suitable basis for formal reasoning. This paper presents λp , a core calculus that captures the essence of ECMAScript 6 promises. Based on λp , we introduce the promise graph, a program representation that can assist programmers with debugging of promise-based code. We then report on a case study in which we investigate how the promise graph can be helpful for debugging errors related to promises in code fragments posted to the StackOverflow website." [@Madsen2017MRA]

- "Embodiments provide call stacks for asynchronous programming. A set of all asynchronous call stacks is found by first identifying all threads and all outstanding tasks that have not yet been completed. Optionally, all outstanding continuation-delegates or lambdas that are in the windows queue waiting to be scheduled and/or all outstanding delegates or lambdas in a language-specific queue are also identified. Next, for each thread, identify whether it was invoked by a continuation-callback and, if so, find the corresponding task/promise. Next, given a task/promise, identify the logical parent task/promise. Optionally, given a delegate or lambda, identify its logical parent task/promise. The sequence of logical tasks/promises constitutes an asynchronous call stack in a program. Further information may optionally be retrieved to make the asynchronous call stack more useful. Finally, given a task/promise, identify the corresponding line number and location in source code." [@Wischik2015CSA]

- "Promises are synchronization constructs that hide the complexity of process synchronisation from the developer by providing a placeholder for the result of a potentially incomplete computation performed in a concurrent process.<br />Promises evaluated by remote processes pose challenges for debugging when the remote computation raises an exception. Current debuggers are either unaware that there is a problem in the remote computation or give developers access only to the context of the remote process. This does not allow developers to interact at the same time with the process that launched the promise and the remote process that executed the promise's computation.<br /> To improve debugging of remote promises, in this paper we propose a debugger interface that presents a unified view of both the original and the remote process, by merging the call chains of the two processes at the point where the promise was created. We exemplify our approach, discuss challenges for making it practical, and illustrate through an initial prototype that it can improve debugging of exceptions in remote promises." [@Leske2016PAD]

- "Time-traveling in the execution history of a program during debugging enables a developer to precisely track and understand the sequence of statements and program values leading to an error. To provide this functionality to real world developers, we embarked on a two year journey to create a production quality time-traveling debugger in Microsoft's open-source ChakraCore JavaScript engine and the popular Node.js application framework." [@Barr2016TTD]

- "This thesis presents a reflective model that we call MIAJ-Meta-level Infrastructure for Asynchronous JavaScript Applications. It is designed for giving support in debugging asynchronous JavaScript programs, and overcoming the challenges of debugging applications based on communicating event-loops." [@Caicedo2014MLE]

- "JavaScript code running in the Node.js runtime is a major platform for developers building cloud, mobile, or IoT applications. A fundamental concept in Node.js programming is the use of asynchronous callbacks and event loops to provide highly responsive applications. While conceptually simple, this programming model contains numerous subtleties and behaviors that are defined implicitly by the current Node.js implementation. This paper presents the first comprehensive formalization of the Node.js asynchronous execution model and defines a high-level notion of async-contexts to formalize fundamental relationships between asynchronous executions in an application. These formalizations provide a foundation for the construction of static or dynamic program analysis tools, support the exploration of alternative Node.js event loop implementations, and provide a high-level conceptual framework for reasoning about relationships between the execution of asynchronous callbacks in a Node.js application." [@Loring2017SAJ]

- "We devise a widely applicable debugging approach to deal with the prevailing issue that bugs cannot be precisely reproduced in nondeterministic complex concurrent programs. A distinct efficient record-and-playback mechanism is designed to record all the internal states of execution including intermediate results by injecting our own bytecode, which does not affect the source code, and, through a two-step data processing mechanism, these data will be aggregated, structured and parallel processed for the purpose of replay in high fidelity while keeping the overhead at a satisfactory level. Docker and Git are employed to create a clean environment such that the execution will be undertaken repeatedly with a maximum precision of reproducing bugs. In our development, several other forefront technologies, such as MongoDB, Spark and Node.js are utilized and smoothly integrated for easy implementation. Altogether, we develop a system for Java Debugging Execution Visualization and Verification (JDevv), a debugging tool for Java although our debugging approach can apply to other languages as well. JDevv also offers an aggregated and interactive visualization for the ease of users’ code verification." [@Wang2016ADA]

- "The invention builds a structure of software objects that captures the historically contingent development of an asynchronous program. The invention builds software objects that represent the resources and subtasks that make up the asynchronous program. The objects are connected into a hierarchy whose structure explicates interactions among the resources and subtasks. When a fault is detected, the structure tells the debugger everything the program was doing at the time of the fault and lays open the developmental history of the program that led to the fault. The debugger uses this information to trace the detected fault back through code and time to its origin. When a new feature is added, the structure tells maintenance personnel how the new feature affects existing functions. Within the structure, the invention provides mechanisms for handling reference counters and software locks. Groups of resources can be handled together, the structure taking care of coordination." [@Joy2011TAE]



- "SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code. It shields the debugger from optimizations performed by the compiler by dynamically deoptimizing code on demand. Deoptimization only affects the procedure activations that are actively being debugged; all other code runs at full speed. Deoptimization requires the compiler to supply debugging information at discrete interrupt points; the compiler can still perform extensive optimizations between interrupt points without affecting debuggability. At the same time, the inability to interrupt between interrupt points is invisible to the user. Our debugging system also handles programming changes during debugging. Again, the system provides expected behavior: it is possible to change a running program and immediately observe the effects of the change. Dynamic deoptimization transforms old compiled code (which may contain inlined copies of the old version of the changed procedure) into new versions reflecting the current source-level state. To the best of our knowledge, SELF is the first practical system providing full expected behavior with globally optimized code." [@Holzle1992DOC] #Deoptimizing #Debugging

- "Context information associated with asynchronous tasks executing in a multithread computer processing environment can be captured. An identifier block having context information associated with tasks executed in the thread is stored in a call stack of a thread. For asynchronous tasks that execute in the thread, a context trace component causes the thread to place an identifier block in the stack of the thread. The identifier block stores context information associated with the currently executing task and with one or more previously executed tasks. Context information currently stored in an identifier block can be retrieved and stored in subsequent identifier blocks, thereby enabling capture of a sequential context trace of asynchronous tasks that execute in the thread. The context trace information stored in the identifier block can be retrieved to support failure analysis when a task fails to execute properly." [@Karppanen2017ECT] #Patent
  - from background: "Debuggers can provide useful information relating to the crashed second thread, such as the position in the program at which it crashed. But the first thread, whose action caused or contributed to the crash of the second thread, continues to execute, and the state of the first thread at the time of the second thread's crash is typically not available for capture. The lack of visibility into the first thread's execution state around the time that the second thread crashed makes it difficult to determine the cause of the second thread's crash. For debugging purposes, it is desirable to determine the source of the asynchronous task that crashed; however, the thread that originated the crashed asynchronous task may have terminated already, or it may have returned from the function that created the asynchronous task that crashed, thereby making it difficult to determine the cause of the crash." [@Karppanen2017ECT]
  
- "A system and method for tracking callback functions for error identification is provided. Prior to a function calling a callback function, it records information relating to the back trace of function(s) that called the callback in a set of state information. In the event of an error condition, the state information may be examined to provide additional information for debugging purposes." [@Massicotte2017SMT]