DOCSLIB.ORG

Address Spaces and Virtual Memory Specification, Implementation, And

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Address Spaces and Virtual Memory Specification, Implementation, And Address Spaces and Virtual Memory Specification, Implementation, and Correctness Dissertation zur Erlangung des Grades Doktor der Ingenieurswissenschaften (Dr.-Ing.) der Naturwissenschaftlich-Technischen Fakult¨at I der Universit¨at des Saarlandes Mark Hillebrand [email protected] Saarbruck¨ en, Juni 2005 ii Tag des Kolloquiums: 13. Juni 2005 Dekan: Prof. Dr. Jor¨ g Eschmeier Vorsitzender des Prufungsausschusses:¨ Prof. Dr.-Ing. Philipp Slusallek 1. Berichterstatter: Prof. Dr. Wolfgang J. Paul 2. Berichterstatter: Prof. Dr. Peter-Michael Seidel 3. Berichterstatter: Prof. Dr. Kurt Mehlhorn akademischer Mitarbeiter: Dr. Sven Beyer Hiermit erklare¨ ich, dass ich die vorliegende Arbeit ohne unzulassige¨ Hilfe Dritter und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus anderen Quellen oder indirekt ubernommenen¨ Daten und Konzepte sind unter Angabe der Quelle gekennzeichnet. Die Arbeit wurde bisher weder im In- noch im Ausland in gleicher oder ahnlicher¨ Form in anderen Prufungsv¨ erfahren vorgelegt. Saarbruck¨ en, im Juni 2005 iii iv “Pretend that you're Hercule Poirot: Examine all clues, and deduce the truth by order and method.” (Donald Knuth. TEX: The Program; Section 1283) Danksagung An dieser Stelle mochte¨ ich allen danken, die zum Gelingen der vorliegenden Arbeit beigetragen haben. Mein Dank gilt zunachst¨ meinen Eltern, die mich wahrend¨ der gesamten Zeit meiner Ausbildung gefordert¨ haben. Herrn Prof. Wolfgang Paul danke ich fur¨ die wissenschaftliche Unterstutzung¨ bei meiner Promotion und die Moglichk¨ eit, meine Arbeit an so interessanter Stelle im Verisoft-Projekt fortsetzen und vertiefen zu konnen.¨ Herrn Wolfgang Pihan und Herrn Dr. Jor¨ g Walter danke ich fur¨ die großzugige¨ Unterstutzung¨ durch IBM, sowie, zusammen mit Frau Dr. Silvia Muller¨ , fur¨ die ursprungliche¨ Idee zu dieser Arbeit. Meiner Freundin Evelyn Becker danke ich fur¨ das aufmerksame und hilfreiche Korrekturlesen dieser fur¨ sie (moglicherweise)¨ sinnfreien Arbeit und fur¨ standige¨ Ermutigung und Ermunterung wahrend¨ der vergangenen Jahre. Danken mochte¨ ich auch meinen (ehemaligen und derzeitigen) Arbeitskollegen, zugleich Freunden, bei der IBM in Boblingen¨ und am Lehrstuhl von Prof. Paul in Saarbruck¨ en. Stellvertretend nenne ich hier meine Zimmerkollegen Markus Braun, Sven Beyer und Thomas In der Rieden. Nicht zuletzt danke ich meinen Freunden Tom Crecelius und Sebastian Schoning,¨ bei denen ich stets Aufnahme und frisch zubereiteten, heißen Tee fand. Die vorliegende Arbeit wurde teilweise von der IBM Entwicklung GmbH (Boblingen)¨ und im Rahmen des Verbundvorhabens Verisoft vom Bundesministerium fur¨ Bildung, Wissenschaft, Forschung und Technologie (BMBF) unter dem Forderk¨ ennzeichen 01 IS C38 gefordert.¨ Die Verantwortung fur¨ den Inhalt dieser Arbeit liegt bei mir. v vi Abstract In modern operating systems tasks operate concurrently on a logical memory. Address spaces control access rights to and the sharing of that memory. They are associated with tasks and manipulated dynamically by memory management operations of the operating system. For cost reasons, logical memory and address spaces are not implemented directly but simulated. The contents of the logical memory are placed in two different mem- ories, the main and the swap memory. Tasks access their address space by using an architecturally defined address translation mechanism, which is implemented by the memory management unit (MMU) and optimized with a translation look-aside buffer (TLB). This mechanism either redirects a memory access to some main memory loca- tion or generates a page fault exception resulting in a call to the page fault handler, a low-level operating system procedure. This construction is correct iff it is transparent to the tasks, so that they behave as if they would operate directly on the logical memory under control of their address spaces. We call the formalization of this correctness criterion a virtual memory simu- lation theorem. In our thesis we formulate and prove such a theorem for an abstract multiprocessor. We apply the theorem to a concrete implementation, a VAMP [BJK+03] with a single- level address translation mechanism and an exemplary page fault handler. We show how to extend the architecture and proofs to support TLBs, multi-level translation, and multiprocessing. Kurzzusammenfassung In modernen Betriebssystemen operieren Programme nebenlaufig¨ auf einem logischen Speicher. Der Zugriff auf diesen Speicher und seine gemeinsame Nutzung wird durch Adressraume¨ geregelt. Diese sind den Programmen zugeordnet und konnen¨ durch Spei- cherverwaltungsoperationen des Betriebssystems dynamisch manipuliert werden. Logischer Speicher und Adressraume¨ werden aus Kostengrunden¨ nicht direkt im- plementiert sondern simuliert. Hierbei verteilen sich die Inhalte des logischen Spei- chers auf zwei verschiedene Speicher, den Haupt- und den Auslagerungsspeicher. Zu- griff auf ihren Adressraum wird den Programmen nur unter Nutzung eines durch die Rechnerarchitektur definierten Adressubersetzungsmechanismus'¨ gewahrt,¨ der durch die Memory Management Unit (MMU) und den Translation Look-Aside Buffer (TLB) implementiert wird. Dieser Mechanismus lenkt einen Zugriff entweder auf eine Haupt- speicheradresse um, oder er erzeugt einen Seitenfehler, der den Aufruf der Seitenfeh- lerbehandlung, eines hardware-nahen Betriebssystemteils, einleitet. Diese Konstruktion ist korrekt, wenn sie fur¨ die Programme transparent ist, das heißt, wenn diese sich mit ihr so verhalten, als griffen sie direkt auf den logischen Speicher unter Kontrolle ihrer Adressraume¨ zu. Die Formalisierung dieser Korrekt- heitsaussage heißt Simulationssatz fur¨ virtuellen Speicher. In der vorliegenden Arbeit formulieren und beweisen wir einen derartigen Satz fur¨ ein abstraktes Mehrprozessorsystem. Wir wenden ihn auf eine konkrete Implementie- rung an, den VAMP [BJK+03] mit einem einstufigen Adressubersetzungsmechanismus¨ und einer exemplarischen Seitenfehlerbehandlung. Wir zeigen, wie Rechnerarchitektur und Korrektheitsbeweise fur¨ die Unterstutzung¨ von TLBs, mehrstufiger Ubersetzung¨ und Mehrprozessorbetrieb erweitert werden konnen.¨ vii Extended Abstract The overall goal of this thesis is to formalize memory and address space models pro- vided by operating systems today and to justify their implementations based on demand paging. This work is divided into two parts. In the first part, we propose a formal, abstract approach to the problem. We develop a model for multitasking with sharing called the relocated memory machine (RMM). In this model, tasks execute concurrently with arbitrary, fair scheduling. Their compu- tation is based on an underlying virtual processor with which they can perform local computation steps and operations on a shared abstract memory. The logical memory, one of its components, serves as a principal data storage. It can be accessed through regular memory operations. These are, however, relocated: the virtual address sup- plied by a task is mapped to a logical address before the operation is performed. Relo- cation thus allows to introduce sharing; two virtual addresses (of two tasks) are shared if their logical addresses are equal. Although relocation already provides simple mem- ory protection, a more fine-grained access control over shared memory regions is de- sirable. Thus, regular memory operations are also subject to a rights check: a memory operation may only be performed (and is then called legal) if it is member of a rights set associated with the virtual address and the task. Collectively, all relocations and rights sets of a certain task are known as its address space. Address spaces form sep- arate components of the shared abstract memory and can be configured dynamically by complex memory operations also called (operating) system calls. To the best of our knowledge, all common address space models and operations can be specified within this model. For cost reasons, the RMM is not implemented directly but simulated. The virtual memory machine (VMM) places the contents of the abstract shared memory in two memories, the main and the swap memory. Its processors run in two different modes. In user mode, a memory operation is subject to address translation: it is either redirected to some main memory location or generates a page fault exception, which makes the processor enter supervisor mode and execute the page fault handler. In the former case, we call the memory operation attached, in the latter detached. While certainly a detached memory operation may be illegal, the typical reason for detachment is that the requested data is stored in swap memory. Hence, the page fault handler loads it to the main memory, updates the address translation accordingly, and returns to user mode where the operation is retried. This strategy is called demand paging [Den70]; it works efficiently if the working sets (locations accessed in a certain time interval) of the user programs fit into the main memory. For the proof of correctness, we proceed in three steps. First, we define a projec- tion function that maps VMM to RMM configurations; it determines the encoding of the logical memory and address spaces. Second, we derive four access conditions; if these hold for an attached and legal memory operation, it is performed equivalently in the VMM and the RMM under the projection function. This result is called step lemma. Third, we derive the runtime conditions that regulate when to attach opera- tions and when not to detach them. For instance: any legal operation,
Load more

Recommended publications
  • Virtual Memory
    Chapter 4 Virtual Memory Linux processes execute in a virtual environment that makes it appear as if each process had the entire address space of the CPU available to itself. This virtual address space extends from address 0 all the way to the maximum address. On a 32-bit platform, such as IA-32, the maximum address is 232 − 1or0xffffffff. On a 64-bit platform, such as IA-64, this is 264 − 1or0xffffffffffffffff. While it is obviously convenient for a process to be able to access such a huge ad- dress space, there are really three distinct, but equally important, reasons for using virtual memory. 1. Resource virtualization. On a system with virtual memory, a process does not have to concern itself with the details of how much physical memory is available or which physical memory locations are already in use by some other process. In other words, virtual memory takes a limited physical resource (physical memory) and turns it into an infinite, or at least an abundant, resource (virtual memory). 2. Information isolation. Because each process runs in its own address space, it is not possible for one process to read data that belongs to another process. This improves security because it reduces the risk of one process being able to spy on another pro- cess and, e.g., steal a password. 3. Fault isolation. Processes with their own virtual address spaces cannot overwrite each other’s memory. This greatly reduces the risk of a failure in one process trig- gering a failure in another process. That is, when a process crashes, the problem is generally limited to that process alone and does not cause the entire machine to go down.
    [Show full text]
  • Jül Spez 0467.Pdf
    EMULATING SIMULA IN TURBO PASCAL by Morton John Canty EMULATING SIMULA IN TURBO PASCAL M. J. Canty 1. lntroduction Although the computer language SIMULA /1,2/ is now over 20 years old it remains an excellent general purpose programming tool as well as a popular and powerfuf simulation language, the purpose for which it was originally developed. SIMULA is an extension of ALGOL 60, which it contains as a true subset, and its advanced concepts have served as a model for modern object-oriented languages such as SMALLTALK. The properties which make SIMULA especially suitable for simulation tasks are 1. a hierarchic cfass concept with inheritance, 2. sophisticated list handfing facilities and 3. concurrent programming capability. Of these three, the most essential property to allow for programming of discrete time simulation tasks is the third one, concurrent programming. By this is meant the ability to sustain parallel autonomous entities (called processes or co-routines) in memory. Allowing an arbitrary number of such processes to interact with each other along a time axis forms the basis of SIMULA's model for discrete time simulation. Although virtually all major programming languages have been implemented in one form or another on personal computers, SIMULA is a notable exception. Perhaps the main reason for this is that, while enjoying great popularity in Europe, SIMULA is not as well known on the North American continent. Pascal belongs to the same Afgol famify as SIMULA, and the dialect Turbo Pascal of the firm Borland Interna­ tional has become one bf the most wide spread high-levef languages for MS-DOS personal computers.
    [Show full text]
  • A Domain-Specific Embedded Language for Probabilistic
    AN ABSTRACT OF THE THESIS OF Steven Kollmansberger for the degree of Master of Science in Computer Science presented on December 12, 2005. Title: A Domain-Specific Embedded Language for Probabilistic Programming Abstract approved: Martin Erwig Functional programming is concerned with referential transparency, that is, given a certain function and its parameter, that the result will always be the same. However, it seems that this is violated in applications involving uncertainty, such as rolling a dice. This thesis defines the background of probabilistic programming and domain-specific languages, and builds on these ideas to construct a domain- specific embedded language (DSEL) for probabilistic programming in a purely functional language. This DSEL is then applied in a real-world setting to develop an application in use by the Center for Gene Research at Oregon State University. The process and results of this development are discussed. c Copyright by Steven Kollmansberger December 12, 2005 All Rights Reserved A Domain-Specific Embedded Language for Probabilistic Programming by Steven Kollmansberger A THESIS submitted to Oregon State University in partial fulfillment of the requirements for the degree of Master of Science Presented December 12, 2005 Commencement June 2006 Master of Science thesis of Steven Kollmansberger presented on December 12, 2005 APPROVED: Major Professor, representing Computer Science Director of the School of Electrical Engineering and Computer Science Dean of the Graduate School I understand that my thesis will become part of the permanent collection of Ore- gon State University libraries. My signature below authorizes release of my thesis to any reader upon request. Steven Kollmansberger, Author ACKNOWLEDGMENTS This thesis would not be possible without the ideas, drive and commitment of many people.
    [Show full text]
  • Virtual Memory - Paging
    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
    [Show full text]
  • Advanced X86
    Advanced x86: BIOS and System Management Mode Internals Input/Output Xeno Kovah && Corey Kallenberg LegbaCore, LLC All materials are licensed under a Creative Commons “Share Alike” license. http://creativecommons.org/licenses/by-sa/3.0/ ABribuEon condiEon: You must indicate that derivave work "Is derived from John BuBerworth & Xeno Kovah’s ’Advanced Intel x86: BIOS and SMM’ class posted at hBp://opensecuritytraining.info/IntroBIOS.html” 2 Input/Output (I/O) I/O, I/O, it’s off to work we go… 2 Types of I/O 1. Memory-Mapped I/O (MMIO) 2. Port I/O (PIO) – Also called Isolated I/O or port-mapped IO (PMIO) • X86 systems employ both-types of I/O • Both methods map peripheral devices • Address space of each is accessed using instructions – typically requires Ring 0 privileges – Real-Addressing mode has no implementation of rings, so no privilege escalation needed • I/O ports can be mapped so that they appear in the I/O address space or the physical-memory address space (memory mapped I/O) or both – Example: PCI configuration space in a PCIe system – both memory-mapped and accessible via port I/O. We’ll learn about that in the next section • The I/O Controller Hub contains the registers that are located in both the I/O Address Space and the Memory-Mapped address space 4 Memory-Mapped I/O • Devices can also be mapped to the physical address space instead of (or in addition to) the I/O address space • Even though it is a hardware device on the other end of that access request, you can operate on it like it's memory: – Any of the processor’s instructions
    [Show full text]
  • Virtual Memory in X86
    Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 x86 Processor Modes • Real mode – walks and talks like a really old x86 chip • State at boot • 20-bit address space, direct physical memory access • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a.
    [Show full text]
  • Virtual Memory
    CSE 410: Systems Programming Virtual Memory Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Address Spaces Paging Summary References Virtual Memory Virtual memory is a mechanism by which a system divorces the address space in programs from the physical layout of memory. Virtual addresses are locations in program address space. Physical addresses are locations in actual hardware RAM. With virtual memory, the two need not be equal. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Address Spaces Paging Summary References Process Layout As previously discussed: Every process has unmapped memory near NULL Processes may have access to the entire address space Each process is denied access to the memory used by other processes Some of these statements seem contradictory. Virtual memory is the mechanism by which this is accomplished. Every address in a process’s address space is a virtual address. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Address Spaces Paging Summary References Physical Layout The physical layout of hardware RAM may vary significantly from machine to machine or platform to platform. Sometimes certain locations are restricted Devices may appear in the memory address space Different amounts of RAM may be present Historically, programs were aware of these restrictions. Today, virtual memory hides these details. The kernel must still be aware of physical layout. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Address Spaces Paging Summary References The Memory Management Unit The Memory Management Unit (MMU) translates addresses. It uses a per-process mapping structure to transform virtual addresses into physical addresses. The MMU is physical hardware between the CPU and the memory bus.
    [Show full text]
  • An Internet Protocol (IP) Address Is a Numerical Label That Is
    Computer Communication Networks Lecture No. 5 Computer Network Lectures IP address An Internet Protocol (IP) address is a numerical label that is assigned to devices participating in a computer network, that uses the Internet Protocol for communication between its nodes. An IP address serves two principal functions: 1- host or network interface identification 2- location addressing. Its role has been characterized as follows: "A name indicates what we seek. An address indicates where it is. A route indicates how to get there." The designers of TCP/IP defined an IP address as a 32-bit number and this system, known as Internet Protocol Version 4 or IPv4, is still in use today. However, due to the enormous growth of the Internet and the resulting depletion of available addresses, a new addressing system (IPv6), using 128 bits for the address, was developed in 1995. Although IP addresses are stored as binary numbers, they are usually displayed in human-readable notations, such as 208.77.188.166 (for IPv4), and 2001:db8:0:1234:0:567:1:1 (for IPv6). The Internet Protocol also routes data packets between networks; IP addresses specify the locations of the source and destination nodes in the topology of the routing system. For this purpose, some of the bits in an IP address are used to designate a sub network. As the development of private networks raised the threat of IPv4 address exhaustion, RFC 1918 set aside a group of private address spaces that may be used by anyone on private networks. They are often used with network address translators to connect to the global public Internet.
    [Show full text]
  • X86 Memory Protection and Translation
    x86 Memory Protection and Translation Don Porter CSE 506 Lecture Goal ò Understand the hardware tools available on a modern x86 processor for manipulating and protecting memory ò Lab 2: You will program this hardware ò Apologies: Material can be a bit dry, but important ò Plus, slides will be good reference ò But, cool tech tricks: ò How does thread-local storage (TLS) work? ò An actual (and tough) Microsoft interview question Undergrad Review ò What is: ò Virtual memory? ò Segmentation? ò Paging? Two System Goals 1) Provide an abstraction of contiguous, isolated virtual memory to a program 2) Prevent illegal operations ò Prevent access to other application or OS memory ò Detect failures early (e.g., segfault on address 0) ò More recently, prevent exploits that try to execute program data Outline ò x86 processor modes ò x86 segmentation ò x86 page tables ò Software vs. Hardware mechanisms ò Advanced Features ò Interesting applications/problems x86 Processor Modes ò Real mode – walks and talks like a really old x86 chip ò State at boot ò 20-bit address space, direct physical memory access ò Segmentation available (no paging) ò Protected mode – Standard 32-bit x86 mode ò Segmentation and paging ò Privilege levels (separate user and kernel) x86 Processor Modes ò Long mode – 64-bit mode (aka amd64, x86_64, etc.) ò Very similar to 32-bit mode (protected mode), but bigger ò Restrict segmentation use ò Garbage collect deprecated instructions ò Chips can still run in protected mode with old instructions Translation Overview 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only ò Segmentation cannot be disabled! ò But can be a no-op (aka flat mode) x86 Segmentation ò A segment has: ò Base address (linear address) ò Length ò Type (code, data, etc).
    [Show full text]
  • Chapter 9: Memory Management
    Chapter 9: Memory Management I Background I Swapping I Contiguous Allocation I Paging I Segmentation I Segmentation with Paging Operating System Concepts 9.1 Silberschatz, Galvin and Gagne 2002 Background I Program must be brought into memory and placed within a process for it to be run. I Input queue – collection of processes on the disk that are waiting to be brought into memory to run the program. I User programs go through several steps before being run. Operating System Concepts 9.2 Silberschatz, Galvin and Gagne 2002 Binding of Instructions and Data to Memory Address binding of instructions and data to memory addresses can happen at three different stages. I Compile time: If memory location known a priori, absolute code can be generated; must recompile code if starting location changes. I Load time: Must generate relocatable code if memory location is not known at compile time. I Execution time: Binding delayed until run time if the process can be moved during its execution from one memory segment to another. Need hardware support for address maps (e.g., base and limit registers). Operating System Concepts 9.3 Silberschatz, Galvin and Gagne 2002 Multistep Processing of a User Program Operating System Concepts 9.4 Silberschatz, Galvin and Gagne 2002 Logical vs. Physical Address Space I The concept of a logical address space that is bound to a separate physical address space is central to proper memory management. ✦ Logical address – generated by the CPU; also referred to as virtual address. ✦ Physical address – address seen by the memory unit. I Logical and physical addresses are the same in compile- time and load-time address-binding schemes; logical (virtual) and physical addresses differ in execution-time address-binding scheme.
    [Show full text]
  • Internet Address Space: Economic Considerations in the Management of Ipv4”, OECD Digital Economy Papers, No
    Please cite this paper as: OECD (2008-06-18), “Internet Address Space: Economic Considerations in the Management of IPv4”, OECD Digital Economy Papers, No. 145, OECD Publishing, Paris. http://dx.doi.org/10.1787/230461618475 OECD Digital Economy Papers No. 145 Internet Address Space ECONOMIC CONSIDERATIONS IN THE MANAGEMENT OF IPV4 OECD DSTI/ICCP(2007)20/FINAL FOREWORD The report provides an analysis of economic considerations associated with the transition from IPv4 to IPv6. It provides background analysis supporting the forthcoming ICCP-organised Ministerial-level meeting on ―The Future of the Internet Economy‖, to take place in Seoul, Korea on 17-18 June 2008. This report was prepared by Ms. Karine Perset of the OECD‘s Directorate for Science Technology and Industry. It was declassified by the ICCP Committee at its 54th Session on 5-7 March 2008. It is published under the responsibility of the Secretary-General of the OECD. This paper has greatly benefited from the expert input of Geoff Huston from APNIC, David Conrad from the IANA, Patrick Grossetête from CISCO Systems, Bill Woodcock from Packet Clearing House, Marcelo Bagnulo Braun from the University of Madrid, Alain Durand from Comcast, and Vincent Bataille from Mulot Déclic, although interpretations, unless otherwise stated, are those of the author. 2 DSTI/ICCP(2007)20/FINAL TABLE OF CONTENTS FOREWORD ................................................................................................................................................... 2 MAIN POINTS ..............................................................................................................................................
    [Show full text]
  • Harmless Advice∗
    Harmless Advice ∗ Daniel S. Dantas David Walker Princeton University Princeton University [email protected] [email protected] Abstract number of calls to each method: The what in this case is the com- when This paper defines an object-oriented language with harmless putation that does the recording and the is the instant of time aspect-oriented advice. A piece of harmless advice is a compu- just prior to execution of each method body. In aspect-oriented ter- what advice tation that, like ordinary aspect-oriented advice, executes when minology, the specification of to do is called and the when pointcut control reaches a designated control-flow point. However, unlike specification of to do it is called a . A collection of ordinary advice, harmless advice is designed to obey a weak non- pointcuts and advice organized to perform a coherent task is called aspect interference property. Harmless advice may change the termination an . behavior of computations and use I/O, but it does not otherwise in- Many within the AOP community adhere to the tenet that as- oblivious fluence the final result of the mainline code. The benefit of harmless pects are most effective when the code they advise is to advice is that it facilitates local reasoning about program behavior. their presence [11]. In other words, aspects are effective when a More specifically, programmers may ignore harmless advice when programmer is not required to annotate the advised code (hence- mainline code reasoning about the partial correctness properties of their programs. forth, the ) in any particular way. When aspect- In addition, programmers may add new pieces of harmless advice oriented languages are oblivious, all control over when advice to pre-existing programs in typical “after-the-fact” aspect-oriented is applied rests with the aspect programmer as opposed to the style without fear they will break important data invariants used by mainline programmer.
    [Show full text]