DOCSLIB.ORG

A Platform for Research Into Object-Level Trace Generation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Platform for Research Into Object-Level Trace Generation View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by CiteSeerX A Platform for Research into Object-Level Trace Generation by James Foucar B.S., Computer Science, University of Texas at Austin, 2003 THESIS Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science Computer Science The University of New Mexico Albuquerque, New Mexico December, 2006 c 2006, James Foucar iii Acknowledgments Special thanks to my advisor, Darko Stefanovi´c, for lots of help, guidance, ideas, and support. Thanks to Steve Blackburn, Matthew Hertz, and Hajime Inoue for giving help and correspondence during this project’s development. Thanks to my committee members Patrick Bridges, Hajime Inoue, and Darko Stefanovi´c. Thanks to my friends at Sandia National Labs, especially Rich, for giving support and donating the computational power needed to complete this project. Thanks to Mom and Dad for their support and helping me proof-read this document. This material is based upon work supported by the National Science Foundation (grants CCR-0085792, CCF-0238027, CCF-0540600). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author and do not neces- sarily reflect the views of the sponsors. iv A Platform for Research into Object-Level Trace Generation by James Foucar ABSTRACT OF THESIS Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science Computer Science The University of New Mexico Albuquerque, New Mexico December, 2006 A Platform for Research into Object-Level Trace Generation by James Foucar B.S., Computer Science, University of Texas at Austin, 2003 M.S., Computer Science, University of New Mexico, 2006 Abstract An object-level trace, which we will hereafter refer to as a garbage collection trace (GC- trace), enumerates all the events that happen during program execution that affect the heap. Therefore, GC-tracing is an excellent way to examine the behavior of an object-oriented system. Knowing behavior expedites many forms of virtual machine research including garbage collection research. GC-traces were originally generated by the painfully slow brute-force technique. Subsequently, this technique was replaced by the Merlin algorithm which can generate GC-traces at a fraction of the cost of the brute-force algorithm. Our work introduces a new GC-tracing system. Our system uses the Merlin algorithm within the context of a general shadow heap that is independent of the virtual machine. The shadow heap supports many optimizations to the Merlin algorithm and also supports analysis and verification. We examine the advantages and disadvantages of our approach, the viability of using a C++ library for analysis in conjunction with a Java-in-Java virtual machine, the various costs of integrating our shadow heap with a virtual machine, and vi the effectiveness of our GC-tracing optimizations. Finally, we compare our GC-tracing system with the GC-tracing system that is currently bundled with JikesRVM. vii Contents 1 Introduction 1 2 Background Material 2 2.1 ObjectBasedSystems............................ 2 2.2 VirtualMachines .............................. 3 2.3 GarbageCollectionvs. Explicitdeallocation . ........ 4 2.4 JikesRVM.................................. 10 2.5 GarbageCollectionTrace. 19 2.6 Merlin.................................... 23 3 Hertz’s Merlin System 28 3.1 High-levelDesign.............................. 28 3.2 Howitworksindetail............................ 29 3.3 TraceI/OIssues............................... 32 4 Shadow-heap-based system 35 viii Contents 4.1 High-levelDesign.............................. 35 4.2 Basicshadowheapalgorithm. 37 4.3 IntegrationwithJikesRVM . 39 4.4 DesignDecisions .............................. 41 4.5 ProjectHistory ............................... 45 5 Comparing the Two Systems 50 5.1 Performance................................. 50 5.2 Robustness ................................. 53 5.3 Capabilities ................................. 55 5.4 GC-TraceDistortion ............................ 56 5.5 GC-Tracequality .............................. 58 5.6 Flexibility.................................. 59 5.7 SoftwareEngineering............................ 61 5.8 Conclusion ................................. 62 6 Optimizations 64 6.1 BootRemsetHeap .............................. 64 6.2 RootDiffHeap................................ 69 6.3 SkipGCUpdateHeap ............................ 73 6.4 Eventbuffering ............................... 75 ix Contents 6.5 Missedopportunities ............................ 76 7 Verification 78 7.1 Eventgranularity:Debugalgorithms . .... 78 7.2 Algorithmicgranularity: Verifier Algorithms . ........ 79 7.3 Difficulties with verification against other systems . .......... 82 8 Results 84 8.1 Performance................................. 84 8.2 Verification ................................. 90 9 Related Work 101 9.1 Oracular................................... 101 9.2 Wolczkopatent ............................... 102 9.3 ShadowProcessing ............................. 103 10 Contributions 104 10.1ShadowHeap ................................ 104 10.2 Optimized Shadow Heaps and Corresponding Verifiers . ....... 105 10.3 AnewGC-tracingsystemforJikesRVM . 105 10.4 ImprovementstoHertz’ssystem . 105 10.5Tools..................................... 105 x Contents 10.6Analysis................................... 106 11 Things Learned 107 11.1 GCAlgorithms ............................... 107 11.2 GC-TracingAlgorithms. 107 11.3JikesRVM.................................. 108 11.4 SoftwareDesign............................... 108 11.5 SystemsProgramming . 108 12 Future Work 109 13 Conclusion 110 A Glossary 113 Glossary 114 B Class diagrams 128 C Usage 132 References 134 xi Chapter 1 Introduction GC-tracing is important tool for garbage collection research. We felt that the GC-tracing system that is bundled with JikesRVM, a popular open source VM code, had some room for improvement and we set out to create a new GC-tracing system that works with JikesRVM. The goals for this system were speed, robustness, and independence from JikesRVM. We decided that these goals could be best achieved by removing the GC-tracing system out of JikesRVM and placing it in an independent C++ library. The creation of this system gave us some good insight into the flaws of the imple- mentation and approach of the previous system. We were able to fix some of these flaws; however, other flaws were inherent to the core algorithm used by both systems. We also gained some insight into the merits of our design approach and GC-tracing in general. In this document, we present our new GC-tracing system, the insights we have gained from our research, and a thorough evaluation of both GC-tracing systems. 1 Chapter 2 Background Material In this chapter we introduce the foundational concepts that our research is based upon. We also introduce the research virtual machine that we worked with and the Merlin algorithm [10, 11] that is the core of our GC-tracing system. Terms that are defined in the glossary are in italics. 2.1 Object Based Systems A large proportion of today’s programming projects are realized using object-oriented (OO) languages. The OO approach is based on the philosophy [21] that related data, and the set of operations on that data, should be encapsulated into a single independent entity: an object. The implementation details of the object and its data are hidden from the code outside the object. Each object allows other objects to interact with it through a well- defined interface which is enumerated in its class definition. An object is an instantiation of its class. The logic of an OO program is usually divided into small pieces called methods. Each method defines an operation upon the object. The operations themselves are typically small and primarily consist of messages to other objects to invoke their methods. 2 Chapter 2. Background Material The OO paradigm is popular because it is believed to be well suited to managing and reducing complexity in large-scale projects. This paradigm produces simple and flexible designs that closely correlate with the problem domain. OO code is also considered to be easier to read and maintain than non-OO code. For these reasons, the OO approach has become ubiquitous in industrial software engineering. 2.2 Virtual Machines When a C program is compiled, it creates a binary executable that consists of a long list of instructions that will be executed by the processor. The only protections from error that the programmer has available are those provided by the operating system. For example, most operating systems provide a paged virtual memory system that protects applications from clobbering memory outside of their virtual address space. In other words, virtual memory systems protect programs from each other. Some memory systems will raise exceptions if a program tries to read/write to a memory segment of the address space that should not be read/written. However, there are still a large number of troublesome types of memory errors that will not be caught by a programmer’s operating system. In a virtual machine environment [17], the virtual machine (VM) is an additional layer between a program and the operating system. Programs are compiled into a format that the virtual machine understands and to execute the program one must execute the virtual machine and provide the compiled program as input. While this approach incurs resource overhead [9], it has the advantage of
Load more

Recommended publications
  • Memory Diagrams and Memory Debugging
    CSCI-1200 Data Structures | Spring 2020 Lab 4 | Memory Diagrams and Memory Debugging Checkpoint 1 (focusing on Memory Diagrams) will be available at the start of Wednesday's lab. Checkpoints 2 and 3 focus on using a memory debugger. It is highly recommended that you thoroughly read the instructions for Checkpoint 2 and Checkpoint 3 before starting. Memory debuggers will be a useful tool in many of the assignments this semester, and in C++ development if you work with the language outside of this course. While a traditional debugger lets you step through your code and examine variables, a memory debugger instead reports memory-related errors during execution and can help find memory leaks after your program has terminated. The next time you see a \segmentation fault", or it works on your machine but not on Submitty, try running a memory debugger! Please download the following 4 files needed for this lab: http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/buggy_lab4. cpp http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/first.txt http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/middle. txt http://www.cs.rpi.edu/academics/courses/spring20/csci1200/labs/04_memory_debugging/last.txt Checkpoint 2 estimate: 20-40 minutes For Checkpoint 2 of this lab, we will revisit the final checkpoint of the first lab of this course; only this time, we will heavily rely on dynamic memory to find the average and smallest number for a set of data from an input file. You will use a memory debugging tool such as DrMemory or Valgrind to fix memory errors and leaks in buggy lab4.cpp.
    [Show full text]
  • Automatic Detection of Uninitialized Variables
    Automatic Detection of Uninitialized Variables Thi Viet Nga Nguyen, Fran¸cois Irigoin, Corinne Ancourt, and Fabien Coelho Ecole des Mines de Paris, 77305 Fontainebleau, France {nguyen,irigoin,ancourt,coelho}@cri.ensmp.fr Abstract. One of the most common programming errors is the use of a variable before its definition. This undefined value may produce incorrect results, memory violations, unpredictable behaviors and program failure. To detect this kind of error, two approaches can be used: compile-time analysis and run-time checking. However, compile-time analysis is far from perfect because of complicated data and control flows as well as arrays with non-linear, indirection subscripts, etc. On the other hand, dynamic checking, although supported by hardware and compiler tech- niques, is costly due to heavy code instrumentation while information available at compile-time is not taken into account. This paper presents a combination of an efficient compile-time analysis and a source code instrumentation for run-time checking. All kinds of variables are checked by PIPS, a Fortran research compiler for program analyses, transformation, parallelization and verification. Uninitialized array elements are detected by using imported array region, an efficient inter-procedural array data flow analysis. If exact array regions cannot be computed and compile-time information is not sufficient, array elements are initialized to a special value and their utilization is accompanied by a value test to assert the legality of the access. In comparison to the dynamic instrumentation, our method greatly reduces the number of variables to be initialized and to be checked. Code instrumentation is only needed for some array sections, not for the whole array.
    [Show full text]
  • Memory Debugging
    Center for Information Services and High Performance Computing (ZIH) Memory Debugging HRSK Practical on Debugging, 03.04.2009 Zellescher Weg 12 Willers-Bau A106 Tel. +49 351 - 463 - 31945 Matthias Lieber ([email protected]) Tobias Hilbrich ([email protected]) Content Introduction Tools – Valgrind – DUMA Demo Exercise Memory Debugging 2 Memory Debugging Segmentation faults sometimes happen far behind the incorrect code Memory debuggers help to find the real cause of memory bugs Detect memory management bugs – Access non-allocated memory – Access memory out off allocated bounds – Memory leaks – when pointers to allocated areas get lost forever – etc. Different approaches – Valgrind: Simulation of the program run in a virtual machine which accurately observes memory operations – Libraries like ElectricFence, DMalloc, and DUMA: Replace memory management functions through own versions Memory Debugging 3 Memory Debugging with Valgrind Valgrind detects: – Use of uninitialized memory – Access free’d memory – Access memory out off allocated bounds – Access inappropriate areas on the stack – Memory leaks – Mismatched use of malloc and free (C, Fortran), new and delete (C++) – Wrong use of memcpy() and related functions Available on Deimos via – module load valgrind Simply run program under Valgrind: – valgrind ./myprog More Information: http://www.valgrind.org Memory Debugging 4 Memory Debugging with Valgrind Memory Debugging 5 Memory Debugging with DUMA DUMA detects: – Access memory out off allocated bounds – Using a
    [Show full text]
  • Advanced Data Structures
    Advanced Data Structures PETER BRASS City College of New York CAMBRIDGE UNIVERSITY PRESS Cambridge, New York, Melbourne, Madrid, Cape Town, Singapore, São Paulo Cambridge University Press The Edinburgh Building, Cambridge CB2 8RU, UK Published in the United States of America by Cambridge University Press, New York www.cambridge.org Information on this title: www.cambridge.org/9780521880374 © Peter Brass 2008 This publication is in copyright. Subject to statutory exception and to the provision of relevant collective licensing agreements, no reproduction of any part may take place without the written permission of Cambridge University Press. First published in print format 2008 ISBN-13 978-0-511-43685-7 eBook (EBL) ISBN-13 978-0-521-88037-4 hardback Cambridge University Press has no responsibility for the persistence or accuracy of urls for external or third-party internet websites referred to in this publication, and does not guarantee that any content on such websites is, or will remain, accurate or appropriate. Contents Preface page xi 1 Elementary Structures 1 1.1 Stack 1 1.2 Queue 8 1.3 Double-Ended Queue 16 1.4 Dynamical Allocation of Nodes 16 1.5 Shadow Copies of Array-Based Structures 18 2 Search Trees 23 2.1 Two Models of Search Trees 23 2.2 General Properties and Transformations 26 2.3 Height of a Search Tree 29 2.4 Basic Find, Insert, and Delete 31 2.5ReturningfromLeaftoRoot35 2.6 Dealing with Nonunique Keys 37 2.7 Queries for the Keys in an Interval 38 2.8 Building Optimal Search Trees 40 2.9 Converting Trees into Lists 47 2.10
    [Show full text]
  • GC Assertions: Using the Garbage Collector to Check Heap Properties
    GC Assertions: Using the Garbage Collector to Check Heap Properties Edward Aftandilian Samuel Z. Guyer Tufts University Tufts University 161 College Ave 161 College Ave Medford MA Medford MA [email protected] [email protected] ABSTRACT The goal of this work is to develop a general mechanism, which GC assertion ex- This paper introduces GC assertions, a system interface that pro- we call a , that allows the programmer to express pected grammers can use to check for errors, such as data structure in- properties of data structures and convey this information to variant violations, and to diagnose performance problems, such as the garbage collector. The key is that many useful, non-trivial prop- memory leaks. GC assertions are checked by the garbage collec- erties can be easily checked by the garbage collector at GC time, tor, which is in a unique position to gather information and answer imposing little or no run-time overhead. The collector triggers the questions about the lifetime and connectivity of objects in the heap. assertion if it finds that the expected properties have been violated. We introduce several kinds of GC assertions, and we describe how While GC assertions require extra programmer effort, they cap- they are implemented in the collector. We also describe our report- ture application-specific properties that programmers want to check ing mechanism, which provides a complete path through the heap and can easily express. For example, we provide a GC assertion to to the offending objects. We show results for one type of asser- verify that a data structure is reclaimed at the next collection when tion that allows the programmer to indicate that an object should the programmer expects it to be garbage.
    [Show full text]
  • Heapviz: Interactive Heap Visualization for Program Understanding and Debugging
    Heapviz: Interactive Heap Visualization for Program Understanding and Debugging 1 Abstract Understanding the data structures in a program is crucial to understanding how the program works, or why it doesn’t work. Inspecting the code that implements the data structures, however, is an arduous task and often fails to yield insights into the global organization of a program’s data. Inspecting the actual contents of the heap solves these problems but presents a significant challenge of its own: finding an effective way to present the enormous number of objects it contains. In this paper we present Heapviz, a tool for visualizing and exploring snapshots of the heap obtained from a running Java program. Unlike existing tools, such as tra- ditional debuggers, Heapviz presents a global view of the program state as a graph, together with powerful interactive capabilities for navigating it. Our tool employs sev- eral key techniques that help manage the scale of the data. First, we reduce the size and complexity of the graph by using algorithms inspired by static shape analysis to aggregate the nodes that make up a data structure. Second, we implement a power- ful visualization component whose interactive interface provides extensive support for exploring the graph. The user can search for objects based on type, connectivity, and field values; group objects; and color or hide and show each group. The user may also inspect individual objects to see their field values and neighbors in the graph. These interactive abilities help the user manage the complexity of these huge graphs. By applying Heapviz to both constructed and real-world examples, we show that Heapviz provides programmers with a powerful and intuitive tool for exploring program behavior.
    [Show full text]
  • Fast As a Shadow, Expressive As a Tree: Hybrid Memory Monitoring for C
    Fast as a Shadow, Expressive as a Tree: Hybrid Memory Monitoring for C Nikolai Kosmatov1 with Arvid Jakobsson2, Guillaume Petiot1 and Julien Signoles1 [email protected] [email protected] SASEFOR, November 24, 2015 A.Jakobsson, N.Kosmatov, J.Signoles (CEA) Hybrid Memory Monitoring for C 2015-11-24 1 / 48 Outline Context and motivation Frama-C, a platform for analysis of C code Motivation The memory monitoring library An overview Patricia trie model Shadow memory based model The Hybrid model Design principles Illustrating example Dataflow analysis An overview How it proceeds Evaluation Conclusion and future work A.Jakobsson, N.Kosmatov, J.Signoles (CEA) Hybrid Memory Monitoring for C 2015-11-24 2 / 48 Context and motivation Frama-C, a platform for analysis of C code Outline Context and motivation Frama-C, a platform for analysis of C code Motivation The memory monitoring library An overview Patricia trie model Shadow memory based model The Hybrid model Design principles Illustrating example Dataflow analysis An overview How it proceeds Evaluation Conclusion and future work A.Jakobsson, N.Kosmatov, J.Signoles (CEA) Hybrid Memory Monitoring for C 2015-11-24 3 / 48 Context and motivation Frama-C, a platform for analysis of C code A brief history I 90's: CAVEAT, Hoare logic-based tool for C code at CEA I 2000's: CAVEAT used by Airbus during certification process of the A380 (DO-178 level A qualification) I 2002: Why and its C front-end Caduceus (at INRIA) I 2006: Joint project on a successor to CAVEAT and Caduceus I 2008: First public release of Frama-C (Hydrogen) I Today: Frama-C Sodium (v.11) I Multiple projects around the platform I A growing community of users.
    [Show full text]
  • Efficient and Programmable Support for Memory Access Monitoring And
    Appears in the Proceedings of the 13th International Symposium on High-Performance Computer Architecture (HPCA-13), February 2007. MemTracker: Efficient and Programmable Support for Memory Access Monitoring and Debugging ∗ Guru Venkataramani Brandyn Roemer Yan Solihin Milos Prvulovic Georgia Tech Georgia Tech North Carolina State University Georgia Tech [email protected] [email protected] [email protected] [email protected] Abstract many of these tasks, performance overheads of such tools are prohibitive, especially in post-deployment monitoring of live Memory bugs are a broad class of bugs that is becoming (production) runs where end users are directly affected by the increasingly common with increasing software complexity, overheads of the monitoring scheme. and many of these bugs are also security vulnerabilities. Un- One particularly important and broad class of program- fortunately, existing software and even hardware approaches ming errors is erroneous use or management of memory for finding and identifying memory bugs have considerable (memory bugs). This class of errors includes pointer arith- performance overheads, target only a narrow class of bugs, metic errors, use of dangling pointers, reads from unini- are costly to implement, or use computational resources in- tialized locations, out-of-bounds accesses (e.g. buffer over- efficiently. flows), memory leaks, etc. Many software tools have been This paper describes MemTracker, a new hardware sup- developed to detect some of these errors. For example, Pu- port mechanism that can be configured to perform different rify [8] and Valgrind [13] detect memory leaks, accesses to kinds of memory access monitoring tasks. MemTracker as- unallocated memory, reads from uninitialized memory, and sociates each word of data in memory with a few bits of some dangling pointer and out-of-bounds accesses.
    [Show full text]
  • Rockjit: Securing Just-In-Time Compilation Using Modular Control-Flow Integrity
    RockJIT: Securing Just-In-Time Compilation Using Modular Control-Flow Integrity Ben Niu Gang Tan Lehigh University Lehigh University 19 Memorial Dr West 19 Memorial Dr West Bethlehem, PA, 18015 Bethlehem, PA, 18015 [email protected] [email protected] ABSTRACT For performance, modern managed language implementations Managed languages such as JavaScript are popular. For perfor- adopt Just-In-Time (JIT) compilation. Instead of performing pure mance, modern implementations of managed languages adopt Just- interpretation, a JIT compiler dynamically compiles programs into In-Time (JIT) compilation. The danger to a JIT compiler is that an native code and performs optimization on the fly based on informa- attacker can often control the input program and use it to trigger a tion collected through runtime profiling. JIT compilation in man- vulnerability in the JIT compiler to launch code injection or JIT aged languages is the key to high performance, which is often the spraying attacks. In this paper, we propose a general approach only metric when comparing JIT engines, as seen in the case of called RockJIT to securing JIT compilers through Control-Flow JavaScript. Hereafter, we use the term JITted code for native code Integrity (CFI). RockJIT builds a fine-grained control-flow graph that is dynamically generated by a JIT compiler, and code heap for from the source code of the JIT compiler and dynamically up- memory pages that hold JITted code. dates the control-flow policy when new code is generated on the fly. In terms of security, JIT brings its own set of challenges. First, a Through evaluation on Google’s V8 JavaScript engine, we demon- JIT compiler is large and usually written in C/C++, which lacks strate that RockJIT can enforce strong security on a JIT compiler, memory safety.
    [Show full text]
  • Speculative Separation for Privatization and Reductions
    Speculative Separation for Privatization and Reductions Nick P. Johnson Hanjun Kim Prakash Prabhu Ayal Zaksy David I. August Princeton University, Princeton, NJ yIntel Corporation, Haifa, Israel fnpjohnso, hanjunk, pprabhu, [email protected] [email protected] Abstract Memory Layout Static Speculative Automatic parallelization is a promising strategy to improve appli- Speculative LRPD [22] R−LRPD [7] cation performance in the multicore era. However, common pro- Privateer (this work) gramming practices such as the reuse of data structures introduce Dynamic PD [21] artificial constraints that obstruct automatic parallelization. Privati- Polaris [29] ASSA [14] zation relieves these constraints by replicating data structures, thus Static Array Expansion [10] enabling scalable parallelization. Prior privatization schemes are Criterion DSA [31] RSSA [23] limited to arrays and scalar variables because they are sensitive to Privatization Manual Paralax [32] STMs [8, 18] the layout of dynamic data structures. This work presents Privateer, the first fully automatic privatization system to handle dynamic and Figure 1: Privatization Criterion and Memory Layout. recursive data structures, even in languages with unrestricted point- ers. To reduce sensitivity to memory layout, Privateer speculatively separates memory objects. Privateer’s lightweight runtime system contention and relaxes the program dependence structure by repli- validates speculative separation and speculative privatization to en- cating the reused storage locations, producing multiple copies in sure correct parallel execution. Privateer enables automatic paral- memory that support independent, concurrent access. Similarly, re- lelization of general-purpose C/C++ applications, yielding a ge- duction techniques relax ordering constraints on associative, com- omean whole-program speedup of 11.4× over best sequential ex- mutative operators by replacing (or expanding) storage locations.
    [Show full text]
  • Secure Virtual Architecture: Using LLVM to Provide Memory Safety to the Entire Software Stack
    Secure Virtual Architecture: Using LLVM to Provide Memory Safety to the Entire Software Stack John Criswell, University of Illinois Andrew Lenharth, University of Illinois Dinakar Dhurjati, DoCoMo Communications Laboratories, USA Vikram Adve, University of Illinois What is Memory Safety? Intuitively, the guarantees provided by a safe programming language (e.g., Java, C#) Array indexing stays within object bounds No uses of uninitialized variables All operations are type safe No uses of dangling pointers Control flow obeys program semantics Sound operational semantics Benefits of Memory Safety for Commodity OS Code Security Memory error vulnerabilities in OS kernel code are a reality1 Novel Design Opportunities Safe kernel extensions (e.g. SPIN) Single address space OSs (e.g. Singularity) Develop New Solutions to Higher-Level Security Challenges Information flow policies Encoding security policies in type system 1. Month of Kernel Bugs (http://projects.info-pull.com/mokb/) Secure Virtual Architecture Commodity OS Virtual ISA Compiler + VM Hardware Native ISA Compiler-based virtual machine underneath software stack Uses analysis & transformation techniques from compilers Supports commodity operating systems (e.g., Linux) Typed virtual instruction set enables sophisticated program analysis Provide safe execution environment for commodity OSs Outline SVA Architecture SVA Safety Experimental Results SVA System Architecture Applications Safety Checking Compiler OS Kernel Drivers OS Memory Allocator SVA ISA Safety Verifier
    [Show full text]
  • Debugging Memory Problems on Cray XT Supercomputers with Totalview Debugger
    Debugging Memory Problems on Cray XT Supercomputers with TotalView Debugger Chris Gottbrath, Ariel Burton TotalView Technologies Robert Moench, Luiz DeRose Cray Inc. ABSTRACT: The TotalView Source Code Debugger gives scientists and engineers a way to debug memory problems on the Cray XT series supercomputer. Memory problems such as memory leaks, array bounds violations, and dangling pointers are difficult to track down with conventional tools on even a simple desktop architecture – they can be much more vexing when encountered on a distributed parallel architecture like that of the XT. KEYWORDS: Programming Environment Tools, Debuggers, Memory Debuggers, Cray XT Series 1. Introduction 2. Classes Of Memory Errors The purpose of this paper is to highlight the Programs typically make use of several different availability of memory debugging on the Cray XT series categories of memory that are managed in different supercomputer. Scientists and engineers taking ways. These include stack memory, heap memory, shared advantage of the unique capabilities of the Cray XT can memory, thread private memory and static or global now identify problems like memory leaks and heap memory. Programmers have to pay special attention, allocation bounds violations – problems that are though, to memory that is allocated out of the Heap extremely difficult and tedious to track down without the Memory. This is because the management of heap kinds of capabilities described here. memory is done explicitly in the program rather than implicitly at compile or run time. We begin by discussing and categorizing memory errors then provide a brief overview of both TotalView There are quite a number of ways that a program can Source Code Debugger and the Cray XT Series.
    [Show full text]