Automated Verification of Practical Garbage Collectors

Garbage collectors are notoriously hard to verify, due to their low-level interaction with the underlying system and the general difficulty in reasoning about reachability in graphs. Several papers have presented verified collectors, but either the proofs were hand-written or the collectors were too simplistic to use on practical applications. In this work, we present two mechanically verified garbage collectors, both practical enough to use for real-world C# benchmarks. The collectors and their associated allocators consist of x86 assembly language instructions and macro instructions, annotated with preconditions, postconditions, invariants, and assertions. We used the Boogie verification generator and the Z3 automated theorem prover to verify this assembly language code mechanically. We provide measurements comparing the performance of the verified collector with that of the standard Bartok collectors on off-the-shelf C# benchmarks, demonstrating their competitiveness

Verification of Shared-Reading Synchronisers

Synchronisation classes are an important building block for shared memory concurrent programs. Thus to reason about such programs, it is important to be able to verify the implementation of these synchronisation classes, considering atomic operations as the synchronisation primitives on which the implementations are built. For synchronisation classes controlling exclusive access to a shared resource, such as locks, a technique has been proposed to reason about their behaviour. This paper proposes a technique to verify implementations of both exclusive access and shared-reading synchronisers. We use permission-based Separation Logic to describe the behaviour of the main atomic operations, and the basis for our technique is formed by a specification for class AtomicInteger, which is commonly used to implement synchronisation classes in java.util.concurrent. To demonstrate the applicability of our approach, we mechanically verify the implementation of various synchronisation classes like Semaphore, CountDownLatch and Lock.Comment: In Proceedings MeTRiD 2018, arXiv:1806.0933

Report on the formal specification and partial verification of the VIPER microprocessor

The formal specification and partial verification of the VIPER microprocessor is reviewed. The VIPER microprocessor was designed by RSRE, Malvern, England, for safety critical computing applications (e.g., aircraft, reactor control, medical instruments, armaments). The VIPER was carefully specified and partially verified in an attempt to provide a microprocessor with completely predictable operating characteristics. The specification of VIPER is divided into several levels of abstraction, from a gate-level description up to an instruction execution model. Although the consistency between certain levels was demonstrated with mechanically-assisted mathematical proof, the formal verification of VIPER was never completed

Subclassing errors, OOP, and practically checkable rules to prevent them

This paper considers an example of Object-Oriented Programming (OOP) leading to subtle errors that break separation of interface and implementations. A comprehensive principle that guards against such errors is undecidable. The paper introduces a set of mechanically verifiable rules that prevent these insidious problems. Although the rules seem restrictive, they are powerful and expressive, as we show on several familiar examples. The rules contradict both the spirit and the letter of the OOP. The present examples as well as available theoretical and experimental results pose a question if OOP is conducive to software development at all.Comment: 10 pages, 1 LaTeX file; accompanying C++ and Haskell code and compilation instruction

Decreasing Duration of Mechanical Restraint Episodes by Increasing Registered Nurse Assessment and Surveillance in an Acute Psychiatric Hospital

Background Application of mechanical restraints is a high-risk emergency measure that requires psychiatric intensive care in order to assure patient safety and expedite release at the earliest opportunity. While current regulations require that trained staff continuously observe restrained individuals, assessment by a registered nurse is required only once an hour. This project builds on research that demonstrated a regulatory change requiring more frequent registered nurse assessments led to decreased duration of mechanical restraint episodes in an acute psychiatric hospital. Purpose The purpose of this project was to implement and evaluate a practice change that required increased frequency of registered nurse assessment and surveillance during mechanical restraint episodes. Methods The nursing department standard requirement for frequency of face-to-face registered nurse assessment and surveillance of patients during episodes of mechanical restraint was increased on pilot units from once every thirty minutes to continuous assessment and surveillance throughout the duration of the restraint application. Quantitative data was collected on hours of duration of restraint episodes on four pilot units for three months before and three months after the intervention and mean duration of episodes was compared before and after the practice change. Results Mean duration of episodes on pilot units decreased 44% in the three months post intervention: 15% on adult units and 70% on the adolescent unit. Conclusion and Recommendation Increasing the frequency of registered nurse assessment and surveillance during mechanical restraint has been shown to decrease duration of restraint episodes. Nurses are encouraged to change practice standards for mechanical restraint, which is a high-risk emergency measure, to provide continuous psychiatric intensive care by a registered nurse. Keywords: mechanical restraint, physical restraint, psychiatric patient

Renaming Global Variables in C Mechanically Proved Correct

Most integrated development environments are shipped with refactoring tools. However, their refactoring operations are often known to be unreliable. As a consequence, developers have to test their code after applying an automatic refactoring. In this article, we consider a refactoring operation (renaming of global variables in C), and we prove that its core implementation preserves the set of possible behaviors of transformed programs. That proof of correctness relies on the operational semantics of C provided by CompCert C in Coq.Comment: In Proceedings VPT 2016, arXiv:1607.0183