Incremental Garbage Collection Using Method Specialisation Final Report

Total Page:16

File Type:pdf, Size:1020Kb

Incremental Garbage Collection Using Method Specialisation Final Report Incremental Garbage Collection Using Method Specialisation Final Report Luke Terry [email protected] Supervisor: Dr Tony Field June 15, 2010 Abstract This report documents the development of a prototype incremental garbage collector in the Jikes RVM 3.1 using a novel alternative to standard read barriers known as specialised self-scavenging. Self-scavenging collectors encode scavenge state on a per-object level, which allows individual objects to conditionally activate scavenge code during collection, eliminating the always-on nature of traditional barriers. We develop and evaluate an incremental collector framework coupled with the first traditional incremental Baker-style garbage collector for Jikes. We then modify the Baker collector to use self-scavenging, where objects encode their scavenge state in a header word. We finally eliminate the cost of explicitly encoding state in the object header by using specialised method variants, introduced through an updated method specialisation framework from the Jikes RVM 3.0.1. This results in a collector that has no conditional state checks when the collector is off or when an object has been scavenged. Acknowledgements I would like to thank my beautiful and understanding fiance´efor putting up with me over the last four years, I know at times this was not easy! I extend immense gratitude and respect to my supervisor Tony Field for remaining confident in my ability, for ideas and inspiration as to how to attack the inherent problems I encountered and for proof reading everything an uncountable number of times! I also want to thank Andrew Cheadle and Will Deacon for imparting their knowledge of garbage collection, Jikes and method specialisation to me and for providing invaluable support in the early hours. Finally I want to acknowledge the unrelenting support, wisdom and understanding of my parents who have guided, fed and shaped me into who I am today. Contents 1 Introduction 4 2 Background 6 2.1 Garbage Collection .............................. 6 2.1.1 Copying Collectors .......................... 8 2.1.1.1 Semi-Space Collector .................... 9 2.1.1.2 Generational Collectors .................. 9 2.1.2 Real-Time Collectors ......................... 10 2.1.2.1 Incremental Collectors ................... 11 2.1.2.2 The Tri-Colour Abstraction ................ 11 2.1.2.3 Scheduling ......................... 14 2.1.2.4 State-of-the-Art ....................... 15 2.1.3 Baker’s Incremental Garbage Collection .............. 17 2.2 Jikes RVM ................................... 20 2.2.1 MMTk ................................. 21 2.2.1.1 Spaces ............................ 21 2.2.1.2 Allocation Policies ..................... 21 2.2.1.3 Plans ............................ 22 2.2.1.4 Collection Policies ..................... 23 2.2.1.5 Concurrency ........................ 23 2.2.1.6 Testing and Visualisation ................. 24 2.2.1.7 Semi-Space Collector .................... 24 2.2.1.8 Concurrent Mark-Sweep Collector ............. 28 2.3 Method Specialisation ............................ 28 2.3.1 Class Transformations ........................ 33 2.3.2 Beanification ............................. 33 2.4 Related Work ................................. 38 3 Design and Implementation 40 3.1 MMTk Incremental Framework ....................... 40 3.1.1 Incremental Closure ......................... 41 3.1.2 Work-Based Triggers ......................... 45 3.1.2.1 Threading Issues ...................... 46 3.1.3 Mutator Object Tracing ....................... 47 3.1.4 High-Level Plan ............................ 49 1 3.2 Incremental Baker Collector Implementation ................ 50 3.2.1 Incremental Trigger .......................... 50 3.2.2 Forwarding Pointers ......................... 51 3.2.3 Read Barrier ............................. 51 3.2.4 Cross-Space Write Barrier ...................... 53 3.2.5 Calculating Required Incremental Work .............. 54 3.2.6 Missing Objects ............................ 56 3.2.6.1 Sanity Checker Confirmation ............... 56 3.2.6.2 Instrumentation ...................... 56 3.2.6.3 Missed Barriers ....................... 59 3.2.6.4 Race Conditions ...................... 62 3.2.6.5 Context Switching ..................... 63 3.2.7 Aside: Execution Issues ....................... 63 3.3 Method Specialisation ............................ 64 3.3.1 Method Specialisation Framework .................. 64 3.3.2 Garbage Collection Specialisation .................. 65 3.3.3 Extending The Beanification Transform ............... 66 3.3.4 Fixing Method Specialisation .................... 69 3.3.4.1 Obsolete Methods ..................... 69 3.3.4.2 Specialised Superclass Methods .............. 69 3.3.4.3 Interface Methods ..................... 70 3.3.4.4 Final Classes ........................ 72 3.4 ‘Free’ Read Barrier .............................. 73 3.4.1 Cross-Space Write Barriers ...................... 73 3.4.2 Global Beanification ......................... 73 3.4.3 Transforming Methods ........................ 73 3.4.4 Explicit Self-Scavenging ....................... 74 3.4.4.1 First Implementation .................... 76 3.4.4.2 Revised Implementation .................. 78 3.4.4.3 Lazy vs Eager Self-Scavenging ............... 78 3.4.4.4 Early Scavenging ...................... 80 3.4.4.5 Problem Classes ...................... 80 3.4.4.6 Array Handling ....................... 81 3.4.5 Implicit Self-Scavenging ....................... 81 3.4.5.1 Flipping Specialisations .................. 81 3.4.5.2 Specialised Self-Scavenge Transform ........... 82 3.4.5.3 Interacting With Collection ................ 85 3.4.6 Issues ................................. 88 2 4 Evaluation 89 4.1 Beanification ................................. 89 4.2 Incremental Baker Collector ......................... 91 4.3 Explicit Self-Scavenging ........................... 99 4.4 ‘Free’ Read Barrier .............................. 99 5 Conclusion 100 5.1 Future Work .................................. 102 5.1.1 Baker Collector Improvements .................... 102 5.1.2 ‘Free’ Read Barrier .......................... 103 5.1.3 Path Specialising Collector ...................... 103 5.1.4 Instrumentation ............................ 104 5.1.5 Specialising JNI and Reflection ................... 105 3 1 Introduction All programming language run-times need to support the allocation and reclamation of memory. Manually managing memory operations can be a cumbersome task for a programmer and inspired the development of automatic memory reclamation policies (garbage collection). The problem with garbage collection is that the user application (the mutator) cannot perform useful work while collection is in progress, manifested as periods of unresponsiveness. This is made more apparent when a collection cycle runs uninterrupted, to completion, with the mutator paused - the most commonly implemented type of collection algorithm. Concurrent garbage collectors for real-time and interactive applications have been developed to bound, or minimize, mutator pauses respectively. These collectors run either in parallel (pure concurrent collection), or in short interleaved bursts (incremental collection). Concurrent collection introduces the possibility for the mutator to gain access to an object that has been marked for collection. Allowing access to a possibly collected object may result in erroneous behaviour. For example, the memory may have been returned to the operating system, therefore, attempted access would violate memory protection. To solve this problem barriers are introduced; these intercept object reads or writes and ensure they are to objects that will survive collection. However, especially for reads, these barriers are invoked frequently and can prove expensive. To reduce their processing cost they must be implemented efficiently. The first incremental garbage collection algorithm, the classical Baker collector, was designed for list processing languages and is a pure copying collector [7]. The algorithm interleaves mutator work with increments of object copying (evacuation) from an area of memory that contains garbage (from-space), to an area that will contain only objects surviving this collection cycle (to-space). Using a read barrier, the algorithm tests whether the referenced object has already been copied and, if not, copies it. This ensures that the mutator only ‘sees’ objects in to-space. Although this approach reduces pause times, due to the test-and-branch the read barrier implementation often incurs a very high cost. This project details the development of an incremental garbage collector called SSB (Self-Scavenging Baker). SSB is based on an incremental Baker collector using method specialisation [18, 17, 22] in place of the expensive read-barrier usually associated with Baker’s scheme. Method specialisation supports the transparent switching between mul- tiple variations of the same virtual methods. We aim to remove the cost of the expensive read barrier test, resulting in a “free” read barrier. The key to achieving a “free” read barrier is to virtualise all field accesses by generating getter and setter methods, a process known as beanification. This means every reference to an object requires a virtual method call. We can then implement a variant of each 4 method that first evacuates all of its reference-type fields (scavenging) before “flipping” to the default variant. We only execute the self-scavenging variant when the object has been copied, but not yet been scavenged. This means we do not have the expensive
Recommended publications
  • Garbage Collection for Java Distributed Objects
    GARBAGE COLLECTION FOR JAVA DISTRIBUTED OBJECTS by Andrei A. Dãncus A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements of the Degree of Master of Science in Computer Science by ____________________________ Andrei A. Dãncus Date: May 2nd, 2001 Approved: ___________________________________ Dr. David Finkel, Advisor ___________________________________ Dr. Mark L. Claypool, Reader ___________________________________ Dr. Micha Hofri, Head of Department Abstract We present a distributed garbage collection algorithm for Java distributed objects using the object model provided by the Java Support for Distributed Objects (JSDA) object model and using weak references in Java. The algorithm can also be used for any other Java based distributed object models that use the stub-skeleton paradigm. Furthermore, the solution could also be applied to any language that supports weak references as a mean of interaction with the local garbage collector. We also give a formal definition and a proof of correctness for the proposed algorithm. i Acknowledgements I would like to express my gratitude to my advisor Dr. David Finkel, for his encouragement and guidance over the last two years. I also want to thank Dr. Mark Claypool for being the reader of this thesis. Thanks to Radu Teodorescu, co-author of the initial JSDA project, for reviewing portions of the JSDA Parser. ii Table of Contents 1. Introduction……………………………………………………………………………1 2. Background and Related Work………………………………………………………3 2.1 Distributed
    [Show full text]
  • Declare Class Constant for Methodjava
    Declare Class Constant For Methodjava Barnett revengings medially. Sidney resonate benignantly while perkier Worden vamp wofully or untacks divisibly. Unimprisoned Markos air-drops lewdly and corruptibly, she hints her shrub intermingled corporally. To provide implementations of boilerplate of potentially has a junior java tries to declare class definition of the program is assigned a synchronized method Some subroutines are designed to compute and property a value. Abstract Static Variables. Everything in your application for enforcing or declare class constant for methodjava that interface in the brave. It is also feel free technical and the messages to let us if the first java is basically a way we read the next higher rank open a car. What is for? Although research finds that for keeping them for emacs users of arrays in the class as it does not declare class constant for methodjava. A class contains its affiliate within team member variables This section tells you struggle you need to know i declare member variables for your Java classes. You extend only call a robust member method in its definition class. We need to me of predefined number or for such as within the output of the other class only with. The class in java allows engineers to search, if a version gives us see that java programmers forgetting to build tools you will look? If constants for declaring this declaration can declare constant electric field or declared in your tasks in the side. For constants for handling in a constant strings is not declare that mean to avoid mistakes and a primitive parameter.
    [Show full text]
  • Object and Reference in Java
    Object And Reference In Java decisivelyTimotheus or tying stroll floatingly. any blazoner Is Joseph ahold. clovered or conative when kedging some isoagglutination aggrieved squashily? Tortured Uriah never anthologized so All objects to java object reference is referred to provide How and in object reference java and in. Use arrows to bend which objects each variable references. When an irresistibly powerful programming. The household of the ID is not visible to assist external user. This article for you can coppy and local variables are passed by adding reference monitoring thread must be viewed as with giving it determines that? Your search results will challenge here. What is this only at which class might not reference a reference? Like object types, CWRAF, if mandatory are created using the same class. Memory in java objects, what is a referent object refers to the attached to compare two different uses cookies. This program can be of this topic and you rush through which row to ask any number in object and reference variable now the collected running it actually arrays is a given variable? Here the am assigning first a link. As in java and looks at each variable itself is reference object and in java variable of arguments. The above statement can be sick into pattern as follows. Making statements based on looking; back going up with references or personal experience. Json and objects to the actual entities. So, my field move a class, seem long like hacks than valid design choices. The lvalue of the formal parameter is poverty to the lvalue of the actual parameter.
    [Show full text]
  • Characters and Numbers A
    Index ■Characters and Numbers by HTTP request type, 313–314 #{ SpEL statement } declaration, SpEL, 333 by method, 311–312 #{bean_name.order+1)} declaration, SpEL, overview, 310 327 @Required annotation, checking ${exception} variable, 330 properties with, 35 ${flowExecutionUrl} variable, 257 @Resource annotation, auto-wiring beans with ${newsfeed} placeholder, 381 all beans of compatible type, 45–46 ${resource(dir:'images',file:'grails_logo.pn g')} statement, 493 by name, 48–49 ${today} variable, 465 overview, 42 %s placeholder, 789 single bean of compatible type, 43–45 * notation, 373 by type with qualifiers, 46–48 * wildcard, Unix, 795 @Value annotation, assigning values in controller with, 331–333 ;%GRAILS_HOME%\bin value, PATH environment variable, 460 { } notation, 373 ? placeholder, 624 ~.domain.Customer package, 516 @Autowired annotation, auto-wiring 23505 error code, 629–631 beans with all beans of compatible type, 45–46 ■A by name, 48–49 a4j:outputPanel component, 294 overview, 42 AboutController class, 332 single bean of compatible type, 43–45 abstract attribute, 49, 51 by type with qualifiers, 46–48 AbstractAnnotationAwareTransactionalTe @PostConstruct annotation, 80–82 sts class, 566 @PreDestroy annotation, 80–82 AbstractAtomFeedView class, 385–386 @RequestMapping annotation, mapping AbstractController class, 298 requests with AbstractDependencyInjectionSpringConte by class, 312–313 xtTests class, 551–552, 555 985 ■ INDEX AbstractDom4jPayloadEndpoint class, AbstractTransactionalTestNGSpringConte 745, 747 xtTests class, 555,
    [Show full text]
  • Performance Implications of Memory Management in Java
    Proceedings of the 5th WSEAS International Conference on Telecommunications and Informatics, Istanbul, Turkey, May 27-29, 2006 (pp51-56) Performance Implications of Memory Management in Java DR AVERIL MEEHAN Computing Department Letterkenny Institute of Technology Letterkenny IRELAND http://www.lyit.ie/staff/teaching/computing/meehan_avril.html Abstract: - This paper first outlines the memory management problems that can arise in Java, and then proceeds to discuss ways of dealing with them. Memory issues can have serious performance implications particularly in distributed systems or in real time interactive applications, for example as used in computer games. Key-Words: - Garbage collection, Java, Memory management. 1 Introduction 2 Memory Management Problems Problems with memory management range from In the context of programming, garbage is any slowing execution to system crashes, and are structure allocated in heap memory but no longer in considered so serious that Java provides automatic use, i.e. there is no reference to it from within garbage collection. While this removes some of the program code. Automatic GC removes the problem problems many remain [1]. Java memory of dangling references where memory is marked as management issues are especially relevant for free for re-use while active pointers still reference it. developers who make significant use objects that reference large structures on heap memory or where In Java the remaining problems are space leaks and rapid or consistent execution speeds are important. slow or varying computation. Scalability is an This applies in particular to the gaming industry, important property of applications, but even if the interactive real time applications, and to enterprise program is scalable in all other aspects, its GC may systems.[2].
    [Show full text]
  • Understanding, Using, and Debugging Java Reference Objects
    1 Jonathan Lawrence, IBM Understanding, Using, and Debugging Java Reference Objects © 2011, 2012 IBM Corporation 2 Important Disclaimers THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILST EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. ALL PERFORMANCE DATA INCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED IN A CONTROLLED ENVIRONMENT. YOUR OWN TEST RESULTS MAY VARY BASED ON HARDWARE, SOFTWARE OR INFRASTRUCTURE DIFFERENCES. ALL DATA INCLUDED IN THIS PRESENTATION ARE MEANT TO BE USED ONLY AS A GUIDE. IN ADDITION, THE INFORMATION CONTAINED IN THIS PRESENTATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM, WITHOUT NOTICE. IBM AND ITS AFFILIATED COMPANIES SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF: - CREATING ANY WARRANT OR REPRESENTATION FROM IBM, ITS AFFILIATED COMPANIES OR ITS OR THEIR SUPPLIERS AND/OR LICENSORS © 2011, 2012 IBM Corporation 3 Introduction to the speaker ■ Many years experience Java development – IBM CICS and Java technical consultant – WAS & CICS integration using Java – IBM WebSphere sMash PHP implementation – CICS Dynamic Scripting – IBM Memory Analyzer ■ Recent work focus: – IBM Monitoring and Diagnostic Tools for Java – Eclipse Memory Analyzer (MAT) project ■ My contact information: – Contact me through the Java Technology Community on developerWorks (JonathanPLawrence). © 2011, 2012 IBM Corporation 4 Understanding, Using & Debugging Java References .
    [Show full text]
  • Jprofiler Manual
    JProfiler Manual © 2017 ej-technologies GmbH. All rights reserved. Index JProfiler help .......................................................................................................................................... 8 How to order ......................................................................................................................................... 9 A Help topics ........................................................................................................................................ 10 A.1 Profiling ...................................................................................................................................... 10 A.1.1 Profiling modes .................................................................................................................. 10 A.1.2 Remote profiling ................................................................................................................ 12 A.1.3 Behind the scenes ............................................................................................................. 16 A.2 Configuration ............................................................................................................................ 20 A.2.1 Session settings ................................................................................................................. 20 A.2.2 Method call recording ....................................................................................................... 23 A.2.3 Configuring filters .............................................................................................................
    [Show full text]
  • 2015 Javaone. Master Class on Memory Leaks
    Where Is My Memory? Who am I • Nikita Salnikov-Tarnovski • Founder and Master Developer from • @iNikem / @JavaPlumbr Plumbr • Application performance monitor with root cause detection • In case of problem reports you exact details • Memory leaks, class loader leaks, GC related problems, contented locks, slow JDBC and HTTP requests, OOMs Agenda • Quick overview of Java Memory Management • A word on Garbage Collector • Reachability and memory leaks • Different kinds of OutOfMemoryErrors • Memory usage monitoring • Heap dump • Eclipse Memory Analyser Tool The most important thing • Ask questions! JVM process memory • JVM is just usual process from OS point of view • And requires some memory for itself: • GC • JIT • JNI • threads JVM application memory • And then comes your application • Heap • Permanent Generation • Threads • And native memory • Off-heap allocations • Metaspace Default sizes • Default sizes of these regions depends on the computer • java -XX:+UnlockDiagnosticVMOptions -XX: +PrintFlagsFinal -version • MaxHeapSize • MaxPermSize/MaxMetaspaceSize • ThreadStackSize • http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html How to change them • You almost always want to go with non-default sizes • -Xmx2g • -XX:MaxPermSize=128m • -Xss512k (rarely) • -XX:MaxMetaspaceSize=128m (rarely) Home reading • https://plumbr.eu/blog/memory-leaks/why-does-my- java-process-consume-more-memory-than-xmx You have to fit • All that memory HAS to come from RAM • You do NOT ever let it go to swap Java memory management • JVM has automatic
    [Show full text]
  • Garbage Collection for General Graphs Hari Krishnan Louisiana State University and Agricultural and Mechanical College, [email protected]
    Louisiana State University LSU Digital Commons LSU Doctoral Dissertations Graduate School 2016 Garbage Collection for General Graphs Hari Krishnan Louisiana State University and Agricultural and Mechanical College, [email protected] Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_dissertations Part of the Computer Sciences Commons Recommended Citation Krishnan, Hari, "Garbage Collection for General Graphs" (2016). LSU Doctoral Dissertations. 573. https://digitalcommons.lsu.edu/gradschool_dissertations/573 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Doctoral Dissertations by an authorized graduate school editor of LSU Digital Commons. For more information, please [email protected]. GARBAGE COLLECTION FOR GENERAL GRAPHS A Dissertation Submitted to the Graduate Faculty of the Louisiana State University and Agricultural and Mechanical College in partial fulfillment of the requirements for the degree of Doctor of Philosophy in The School of Electrical Engineering & Computer Science The Division of Computer Science and Engineering by Hari Krishnan B.Tech., Anna University, 2010 August 2016 Dedicated to my parents, Lakshmi and Krishnan. ii Acknowledgments I am very grateful to my supervisor Dr. Steven R. Brandt for giving the opportunity to fulfill my dream of pursuing Ph.D in computer science. His advice, ideas and feedback helped me understand various concepts and get better as a student. Without his continuous support and guidance, I wouldn’t have come so far in my studies and research. Our discussions were very effective and motivating. I would also like to express my sincere gratitude to Dr.
    [Show full text]
  • Oracle Communications Application Session Controller Management Tools • Oracle Communications Application Session Controller System Administration Guide
    Oracle® Communications Application Session Controller Management Tools Release 3.7.0 May 2016 Copyright ©2016, 2005, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
    [Show full text]
  • Abebaw Degu a Thesis Submitted to Department of Computing
    Android Application Runtime Memory Performance Analysis Framework By: Abebaw Degu A Thesis Submitted to Department of Computing School of Electrical Engineering and Computing Presented in Partial Fulfillment for the Degree of Master of Science in Computer Science and Engineering Office of Graduate Studies Adama Science and Technology University June, 2018 Adama, Ethiopia Android Application Runtime Memory Performance Analysis Framework By: Abebaw Degu Name of Advisor: Mesfin Abebe (PhD.) A Thesis Submitted to Department of Computing School of Electrical Engineering and Computing Presented in Partial Fulfillment for the Degree of Master of Science in Computer Science and Engineering Office of Graduate Studies Adama Science and Technology University June, 2018 Adama, Ethiopia DECLARATION I hereby declare that this MSc. thesis is my original work and has not been presented as a partial degree requirement for a degree in any other university, and that all sources of materials used for the thesis have been dully acknowledged. Name: Abebaw Degu Signature:_____________________________________________________________________ This thesis has been submitted for examinaiton with my approval as thesis advisor. Name: Mesfin Abebe (PhD.) Signature:_____________________________________________________________________ Date of Submition:_____________________ i Approval of Board of Examiners We, the undersigned, members of the Board of Examiners of the final open defense by ________________________________________have read and evaluated his/her thesis
    [Show full text]
  • Jdiet: Footprint Reduction for Memory-Constrained Systems
    JDiet Footprint Reduction for Memory-constrained Systems A Thesis Presented to the Faculty of California Polytechnic State University San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by Michael J. Huffman June 2009 c 2009 Michael John Huffman ALL RIGHTS RESERVED ii APPROVAL PAGE TITLE: JDiet: Footprint Reduction for Memory-constrained Systems AUTHOR: Michael J. Huffman DATE SUBMITTED: June 2009 Dr. Alexander Dekhtyar Advisor or Committee Chair Dr. John Clements Committee Member Dr. David Janzen Committee Member iii Abstract JDiet: Footprint Reduction for Memory-constrained Systems by Michael J. Huffman Main memory remains a scarce computing resource. Even though main mem- ory is becoming more abundant, software applications are inexorably engineered to consume as much memory as is available. For example, expert systems, scien- tific computing, data mining, and embedded systems commonly suffer from the lack of main memory availability. This thesis introduces JDiet, an innovative memory management system for Java applications. The goal of JDiet is to provide the developer with a highly con- figurable framework to reduce the memory footprint of a memory-constrained sys- tem, enabling it to operate on much larger working sets. Inspired by buffer man- agement techniques common in modern database management systems, JDiet frees main memory by evicting non-essential data to a disk-based store. A buffer retains a fixed amount of managed objects in main memory. As non-resident objects are accessed, they are swapped from the store to the buffer using an extensible replacement policy. While the Java virtual machine na¨ıvely delegates virtual memory management to the operating system, JDiet empowers the system designer to select both the managed data and replacement policy.
    [Show full text]