Horatiu Jula

Communix: A framework for collaborative deadlock immunity

We present Communix, a collaborative deadlock immunity framework for Java programs. Deadlock immunity enables applications to avoid deadlocks that they previously encountered. Dimmunix [1], our deadlock immunity system, detects deadlocks and saves their signatures at runtime, then avoids execution flows that match these signatures; a signature is an abstraction of the execution flow that led to deadlock. Dimmunix needs all the deadlock bugs in an application to manifest, in all possible ways, in order to provide full protection against deadlocks for that application. Communix addresses this shortcoming by distributing the deadlock signatures produced by Dimmunix. The signatures of a deadlock can protect against the deadlock any user connected to the Internet and running the same application, even if he/she did not experience the deadlock yet. Besides signature distribution, Communix provides signature validation and generalization. Signature validation ensures that the incoming signatures match the target applications, and protect the users against malicious signatures. Signature generalization keeps the repository of deadlock signatures compact, by merging multiple deadlock signatures into one signature. Communix is application agnostic, i.e., it is applicable to any Java application. Communix is efficient and scalable, and can effectively protect Java applications against malicious signatures.

A Scalable, Sound, Eventually-Complete Algorithm for Deadlock Immunity

We introduce the concept of deadlock immunity --a programs ability to avoid all deadlocks that match patterns of deadlocks experienced in the past. We present here an algorithm for enabling large software systems to automatically acquire such immunity without any programmer assistance. We prove that the algorithm is sound and complete with respect to the immunity property. We implemented the algorithm as a tool for Java programs, and measurements show it introduces only modest performance overhead in real, large applications like JBoss. Deadlock immunity is as useful as complete freedom from deadlocks in many practical cases, so we see the present algorithm as a pragmatic step toward ridding complex concurrent programs of their deadlocks.

Platform-wide deadlock immunity for mobile phones

We present an implementation of our deadlock immunity system, Dimmunix, for mobile phone software. Within Android 2.2 OS, we modified Dalvik VM, the JVM running all the Android applications, to provide platform-wide deadlock immunity. We successfully ran the Dimmunix-enabled Android 2.2 OS on a Nexus One phone. On the phone, we reproduced a real deadlock involving Androids NotificationManagerService and StatusBarService classes, which froze the entire phones interface. Android Dimmunix successfully detected the deadlock, and subsequently prevented its reoccurrence, with no user intervention. Our tests show that Android Dimmunix incurs 4–5% performance overhead and 4% memory overhead. Therefore, Android Dimmunix is a practical and efficient solution to cope with deadlocks on mobile phones. To the best of our knowledge, Android Dimmunix is the first failure immunity system for mobile phones, and the first one to provide platform-wide failure immunity.

Efficiency optimizations for implementations of deadlock immunity

Deadlock immunity is a property by which programs, once afflicted by a deadlock, develop resistance against future occurrences of that deadlock. Our deadlock immunity system, called Dimmunix, provides transparent immunization against deadlocks involving mutex locks. In this paper, we focus on efficiently protecting systems against deadlocks regardless of the rate of synchronization operations performed. We describe five optimizations that reduce the runtime overhead imposed by Dimmunix on the host system: (1) offline deadlock detection and signature extraction, which avoids runtime tracking of lock-to-thread allocations; (2) selective program instrumentation, whereby only vulnerable synchronization statements are monitored; (3) inline matching of deadlock signatures, which avoids expensive call stack retrieval; (4) false positive reduction, which avoids unnecessary thread serialization; and (5) safe early resumption of threads, allowing suspended threads to resume their execution more quickly than in the original Dimmunix. Our optimizations enable Dimmunix to achieve a reduction of 2.8x-5.2x in the runtime overhead it introduces for real-world systems like Eclipse, Vuze, and MySQL JDBC.

iProve: A scalable technique for consumer-verifiable software guarantees

Formally proving complex program properties is still considered impractical for systems with over a million lines of code. We present iProve, an approach that enables guaranteeing useful properties in large Java systems. Desired properties are proven in iProve as a combination of two proofs: one of a complex property applied to a small piece of code—a nucleus—using existing theorem provers, and a proof of a simple property applied to the rest of the code—the program body—using iProve. We show how iProve can be used to guarantee properties such as communication security, deadlock immunity, data privacy, and resource usage bounds in Java programs with millions of lines of code. iProve scales well, requires no access to source code, and allows nuclei to be reused with an unlimited number of systems and to be written in verification-friendly languages.

Alternative Implementation of the C# Iterator Blocks.

In this paper, we propose an alternative implementation of the C# iterator blocks in terms of standard C# constructions. This implementation is based on syntactic sugar, so as the implementation described in the C# specification. Unlike the standard implementation, the syntactically transformed code that implements the iterator blocks is executed in a separate thread in a server-like manner by an enumerator object that handles access requests for its elements. The interface, represented by client routines such as MoveNext(), Current, Dispose() or Reset(), accesses the iterator in a thread-safe manner. The synchronization between these two layers is done using well known routines like lock(), Pulse() or Wait().