Scispace (Formerly Typeset)
  1. Home
  2. Conferences
  3. Programming Languages and Operating Systems
  4. 2011
  1. Home
  2. Conferences
  3. Programming Languages and Operating Systems
  4. 2011
Showing papers presented at "Programming Languages and Operating Systems in 2011"
Proceedings Article•10.1145/2039239.2039245•
Preliminary design of the SAFE platform

[...]

André DeHon1, Ben Karel1, Thomas F. Knight2, Gregory Malecha3, Benoit Montagu1, Robin Morisset4, Greg Morrisett3, Benjamin C. Pierce1, Randy Pollack3, Sumit Ray2, Olin Shivers5, Jonathan M. Smith1, Gregory T. Sullivan2 •
University of Pennsylvania1, BAE Systems2, Harvard University3, École Normale Supérieure4, Northeastern University5
23 Oct 2011
TL;DR: Though the project is still at an early stage, it has assembled a set of basic architectural choices that it is believed will yield a high-assurance system.
Abstract: Safe is a clean-slate design for a secure host architecture. It integrates advances in programming languages, operating systems, and hardware and incorporates formal methods at every step. Though the project is still at an early stage, we have assembled a set of basic architectural choices that we believe will yield a high-assurance system. We sketch the current state of the design and discuss several of these choices.

23 citations

Proceedings Article•10.1145/2039239.2039248•
Using declarative invariants for protecting file-system integrity

[...]

Jack Sun1, Daniel Fryer1, Ashvin Goel1, Angela Demke Brown1•
University of Toronto1
23 Oct 2011
TL;DR: It is argued that using a declarative language to express and check consistency invariants improves the clarity of the rules, making them easier to reason about, verify, and port to new file systems.
Abstract: We have been developing a framework, called Recon, that uses runtime checking to protect the integrity of file-system metadata on disk. Recon performs consistency checks at commit points in transaction-based file systems. We define declarative statements called consistency invariants for a file system, which must be satisfied by each transaction being committed to disk. By checking each transaction before it commits, we prevent any corruption to file-system metadata from reaching the disk.Our prototype system required writing the consistency invariants in C. In this paper, we argue that using a declarative language to express and check these invariants improves the clarity of the rules, making them easier to reason about, verify, and port to new file systems. We describe how file system invariants can be written and checked using the Datalog declarative language in the Recon framework.

11 citations

Proceedings Article•10.1145/2039239.2039241•
Finding resource-release omission faults in Linux

[...]

Suman Saha, Julia Lawall1, Gilles Muller2•
University of Copenhagen1, French Institute for Research in Computer Science and Automation2
23 Oct 2011
TL;DR: This paper proposes an approach to finding resource-release omission faults in C code that takes into account the choice of resource-releasing operation may depend on the context in which it is to be used, and uses it to find over 100 faults in the drivers directory of Linux 2.6.34.
Abstract: The management of the releasing of allocated resources is a continual problem in ensuring the robustness of systems code. Missing resource-releasing operations lead to memory leaks and deadlocks. A number of approaches have been proposed to detect such problems, but they often have a high rate of false positives, or focus only on commonly used functions. In this paper we observe that resource-releasing operations are often found in error-handling code, and that the choice of resource-releasing operation may depend on the context in which it is to be used. We propose an approach to finding resource-release omission faults in C code that takes into account these issues. We use our approach to find over 100 faults in the drivers directory of Linux 2.6.34, with a false positive rate of only 16%, well below the 30% that has been found to be acceptable to developers.

9 citations

Proceedings Article•10.1145/2039239.2039244•
Rounding pointers: type safe capabilities with C++ meta programming

[...]

Alexander Warg1, Adam Lackorzynski1•
Dresden University of Technology1
23 Oct 2011
TL;DR: This paper presents an object-oriented framework that uses the C++ programming language to offer a frame-work for building and using operating-system components and applications.
Abstract: Recent trends in secure operating systems indicate that an object-capability system is the security model with pre-eminent characteristics and practicality. Unlike traditional operating systems, which use a single global name space, object-capability systems name objects per protection domain. This allows a fine-grained isolation of the domains and follows the principle of least authority.Programming in such an environment differs considerably from traditional programming models. The fine-grained access to functionality requires a programming environment that supports the programmer when using a capability system. In this paper, we present an object-oriented framework that uses the C++ programming language to offer a frame-work for building and using operating-system components and applications.

8 citations

Proceedings Article•10.1145/2039239.2039242•
Configuration coverage in the analysis of large-scale system software

[...]

Reinhard Tartler1, Daniel Lohmann1, Christian Dietrich1, Christoph Egger1, Julio Sincero1 •
University of Erlangen-Nuremberg1
23 Oct 2011
TL;DR: A metric for configuration coverage (CC) is presented and the challenges for (properly) calculating it are explained and an efficient approach is presented for determining a sufficiently small set of configurations that achieve (nearly) full coverage and evaluate it on a recent Linux kernel version.
Abstract: System software, especially operating systems, tends to be highly configurable. Like every complex piece of software, a considerable amount of bugs in the implementation has to be expected. In order to improve the general code quality, tools for static analysis provide means to check for source code defects without having to run actual test cases on real hardware. Still, for proper type checking a specific configuration is required so that all header include paths are available and all types are properly resolved.In order to find as many bugs as possible, usually a "full configuration" is used for the check. However, mainly because of alternative blocks in form of #else-blocks, a single configuration is insufficient to achieve full coverage. In this paper, we present a metric for configuration coverage (CC) and explain the challenges for (properly) calculating it. Furthermore, we present an efficient approach for determining a sufficiently small set of configurations that achieve (nearly) full coverage and evaluate it on a recent Linux kernel version.
Proceedings Article•10.1145/2039239.2039251•
URDB: a universal reversible debugger based on decomposing debugging histories

[...]

Ana-Maria Visan1, Kapil Arya1, Gene Cooperman1, Tyler Denniston1•
Northeastern University1
23 Oct 2011
TL;DR: An essential novelty of this work is the extension of DMTCP to be the first checkpointing package capable of checkpointing a GDB sesssion to disk (through checkpointing the Linux ptrace system call).
Abstract: Reversible debuggers have existed since the early 1970s. A novel approach, URDB, is introduced based on checkpoint/re-execute. It adds reversibility to a debugger, while still placing the end user within the familiar environment of their preferred debugger. The URDB software layer currently includes modes that understand the syntax for four debuggers: GDB for C/C++/Java/Fortran, Python (pdb), MATLAB, and Perl (perl -d). It does so by adding a thin URDB software layer on top of the DMTCP checkpoint-restart package. URDB passes native debugging commands between the end user and the underlying debugging session. URDB models the four common debugging primitives that form the basis for most debuggers: step, next, continue, break. For example, given a debugging history of the form [step, next, step], URDB's reverse-step produces a new history, [step, next]. Further, subtle algorithms are described for reverse-xxx. For example, reverse-step operates correctly when the last instruction of the history is next or continue.URDB calls DMTCP to create a checkpoint during a de-bugging session, and then replays the history from there. An essential novelty of this work is the extension of DMTCP to be the first checkpointing package capable of checkpointing a GDB sesssion to disk (through checkpointing the Linux ptrace system call). This was a significant barrier to earlier attempts toward checkpoint/re-execute for GDB. Support for the GDB debugger is important to any reversible debugger claiming universality. Experimental results are described for GDB, MATLAB, Python (pdb), and Perl.
Proceedings Article•10.1145/2039239.2039249•
Assessing the scalability of garbage collectors on many cores

[...]

Lokesh Gidra1, Gaël Thomas1, Julien Sopena1, Marc Shapiro1•
Pierre-and-Marie-Curie University1
23 Oct 2011
TL;DR: In this article, the authors explore the costs and scalability of the garbage collector on a contemporary 48-core multiprocessor machine and present experimental evaluation of the parallel and concurrent garbage collectors present in OpenJDK, a widely-used Java virtual machine.
Abstract: Managed Runtime Environments (MRE) are increasingly used for application servers that use large multi-core hardware. We find that the garbage collector is critical for overall performance in this setting. We explore the costs and scalability of the garbage collectors on a contemporary 48-core multiprocessor machine. We present experimental evaluation of the parallel and concurrent garbage collectors present in OpenJDK, a widely-used Java virtual machine. We show that garbage collection represents a substantial amount of an application's execution time, and does not scale well as the number of cores increases. We attempt to identify some critical scalability bottlenecks for garbage collectors.
Proceedings Article•10.1145/2039239.2039247•
Dynamic deadlock avoidance in systems code using statically inferred effects

[...]

Prodromos Gerakios1, Nikolaos Papaspyrou1, Konstantinos Sagonas1, Panagiotis Vekris1•
National Technical University of Athens1
23 Oct 2011
TL;DR: This paper presents a tool that uses a sound static analysis to instrument multithreaded C programs and then links these programs with a run-time system that avoids possible deadlocks, in contrast to most other purely static tools for deadlock freedom.
Abstract: Deadlocks can have devastating effects in systems code. We have developed a type and effect system that provably avoids them and in this paper we present a tool that uses a sound static analysis to instrument multithreaded C programs and then links these programs with a run-time system that avoids possible deadlocks. In contrast to most other purely static tools for deadlock freedom, our tool does not insist that programs adhere to a strict lock acquisition order or use lock primitives in a block-structured way, thus it is appropriate for systems code and OS applications. We also report some very promising benchmark results which show that all possible deadlocks can automatically be avoided with only a small run-time overhead. More importantly, this is done without having to modify the original source program by altering the order of resource acquisition operations or by adding annotations.

Tools

SciSpace AgentBiomedical AgentSciSpace RecruitSciSpace for EnterpriseAgent GalleryChat with PDFLiterature ReviewAI WriterFind TopicsParaphraserCitation GeneratorExtract DataAI DetectorCitation Booster

Learn

ResourcesLive Workshops

SciSpace

CareersSupportBrowse PapersPricingSciSpace Affiliate ProgramCancellation & Refund PolicyTermsPrivacyData Sources

Directories

PapersTopicsJournalsAuthorsConferencesInstitutionsCitation StylesWriting templates

Extension & Apps

SciSpace Chrome ExtensionSciSpace Mobile App

Contact

support@scispace.com
SciSpace

© 2026 | PubGenius Inc. | Suite # 217 691 S Milpitas Blvd Milpitas CA 95035, USA

soc2
Secured by Delve