DOCSLIB.ORG

Aspect-Oriented Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Beyond OOP Advanced Separation of Concerns Metaprogramming Reflection Aspect-Oriented Programming Eric Tanter DCC/CWR University of Chile [email protected] Éric Tanter – U.Chile [june | 2005] 1 Contents ● A brief history of programming ● Advanced modularization problems ● Reflection and metaprogramming ● Aspect-oriented programming Éric Tanter – U.Chile [june | 2005] 2 Part I A Quick History of Programming Adapted from Brian Hayes, “The Post-OOP Paradigm”, American Scientist, 91(2), March-April 2003, pp. 106-110 Éric Tanter – U.Chile [june | 2005] 3 Software? ● Real challenge: building the machine ● Software was not important as such ● First programs (40's) ● Written in pure binary: 0s and 1s ● Explicit memory address management Éric Tanter – U.Chile [june | 2005] 4 Then came the assembly... ● Assembly language ● No more raw binary codes ● Symbols: load, store, add, sub ● Converted to a binary program by an assembler ● Calculates memory addresses ● First program to help programming Éric Tanter – U.Chile [june | 2005] 5 ...and then, compilers ● Assembly required knowledge of the specific computer instruction set ● Higher-level languages (e.g. Fortran) ● Think in terms of variables/equations ● Not registers/addresses ● 60's: big projects = late/costly/buggy Éric Tanter – U.Chile [june | 2005] 6 Structured Programming ● Manifesto by Edsger W. Dijkstra: “Go to statement considered harmful” [1968] ● Build programs out of sub-units ● Single entrance point, single exit ● 3 constructs: ● Sequencing, alternation, and iteration ● Proof that these 3 idioms are sufficient to express all programs by Bohm & Jacopini [1966] Éric Tanter – U.Chile [june | 2005] 7 Structured Programming ● Early programming principles ● Top-down design and stepwise refinement ● Dijkstra [1968] ● Introduction of the notion of modularity and the principle of Separation of Concerns (SOC) ● Self-contained units with interfaces between them ● Parnas [1972] ● Notion of encapsulation (data hiding) ● Internal working of modules kept private Éric Tanter – U.Chile [june | 2005] 8 Variety of Paradigms ● Different ways of structuring programs ● Functional, declarative, logic, procedural, object- oriented... ● Ways to solve a problem ● through divide-and-conquer ● Decompose – solve – recompose Éric Tanter – U.Chile [june | 2005] 9 Object orientation ● Problem with procedural programs ● Procedures and data structures are separate but interdependent ● Changing implementation ● Changing representation ● Contribution of OOP ● Pack data and procedures together ● Objects communicate through messages Éric Tanter – U.Chile [june | 2005] 10 Object orientation ● Key mechanisms ● Instantiation (or cloning) ● Inheritance ● Polymorphism ● Aggregation and delegation Éric Tanter – U.Chile [june | 2005] 11 Object-oriented languages ● Origins ● SIMULA by Dahl and Nygaard (60s) ● SIMULA I (62-65), SIMULA 67 (inheritance) ● Parnas ideas on encapsulation ● Smalltalk (70s) ● Alan Kay & Co. at Xerox PARC ● Introduce GUI and interactive program execution ● Then ● C++, Smalltalk-80, Java, ... ● OO versions of older languages, e.g. CLOS Éric Tanter – U.Chile [june | 2005] 12 Part II Advanced Modularization Problems in (OO) Programs Éric Tanter – U.Chile [june | 2005] 13 OOP Promises ● Major objectives ● Evolution, extension ● Maintenance ● Reuse ● Additional mechanisms ● Frameworks ● Design Patterns [GoF95] ● “the quality without a name” [Alexander,1979] Éric Tanter – U.Chile [june | 2005] 14 Apache Tomcat case study ● Realized by AspectJ folks ● eclipse.org/aspectj ● Illustrates modularization problems in the Apache Tomcat engine Éric Tanter – U.Chile [june | 2005] 15 XML Parsing in Tomcat ● Cleanly modularized in one class Éric Tanter – U.Chile [june | 2005] 16 URL Pattern matching in Tomcat ● Cleanly modularized ● one abstract class/interface and one class Éric Tanter – U.Chile [june | 2005] 17 Logging in Tomcat ● Is this modularized??? Éric Tanter – U.Chile [june | 2005] 18 Session Expiration in Tomcat ● Is this modularized??? Éric Tanter – U.Chile [june | 2005] 19 Problem: decomposition ● Challenge in OOP ● The right decomposition into classes/objects ● e.g., modeling polygons, animals, ... ● Tyranny of the dominant decomposition ● Some issues are not easily arranged in a tree-like hierarchy ● Multiple inheritance (C++) ● Complex semantics due to merging conflicts Éric Tanter – U.Chile [june | 2005] 20 Problem: modularization ● Fact: code scattering ● Code replication = same code repeated in different places ● Code tangling = code for different concerns in the same place ● Why? ● Nature of concerns Éric Tanter – U.Chile [june | 2005] 21 Nature of concerns ● Some concerns are not related to application logic ● exception handling, security, persistence, distri- bution, concurrency, etc. ● Such non-functional concerns are often mixed with the application logic Éric Tanter – U.Chile [june | 2005] 22 Nature of concerns ● Some concerns do not fit in the global decomposi- tion scheme ● They crosscut the application's structure ● Usually handle interactions between modules ● e.g., display update in graphic editor Éric Tanter – U.Chile [june | 2005] 23 Example public void withdraw (double amount) throws NotAllowedException { if(!authorized(Thread.currentThread()) throw new NotAllowedException(); try { checkAmount(amount); doWithdraw(amount); notifyListeners(); } catch(LimitAmountExceeded e){ doWithdraw(e.getMaxAmount()); } } This is code tangling Éric Tanter – U.Chile [june | 2005] 24 Example boolean search(Object e){ boolean found = false; Enumeration elems = this.elements(); while(!found && (elems.hasMoreElements())) found = e.equals(elems.nextElement()) return found; } ● Should be located in many classes (that under- stand the elements() message) ● Such classes are not located in the same class hierarchy: this is a crosscutting concern Éric Tanter – U.Chile [june | 2005] 25 Example ● Design patterns ● Provide design reuse, but no code reuse ● Some patterns lead to tangled code register(this) Observer 1 Subject stateChanged(this) notifyObservers() Observer 2 Éric Tanter – U.Chile [june | 2005] 26 Summary of Issues ● Tangled code ● Readability is decreased ● Detecting/resolving errors ● Reusability is killed ● Replicated code ● Hard to evolve, extend, maintain ● Crosscutting concerns ● No explicit structure ● Hard to reason about, have a global vision Éric Tanter – U.Chile [june | 2005] 27 “Post-OOP” ● Address modularization issues further ● Extend OOP rather than replace it ● Program generation ● Metaprogramming and reflection ● Aspect-oriented programming ● Etc... ● Adaptive programming, composition filters, hyper- spaces, subject-oriented programming, ... Éric Tanter – U.Chile [june | 2005] 28 Generative Programming ● Transform high-level specs into a ready-to-run program ● Old dream ● Area of success: compiler compilers ● Take grammar as input and generate compilers ● Generative Programming ● Idem for other domains ● Manufacturing, product-line engineering ● Create families of tailored programs Éric Tanter – U.Chile [june | 2005] 29 Modularity Requirements ● Concerns in their own modules ● “Connect” them at appropriate places ● Issues ● Intrusiveness, obliviousness ● Symmetry of the approach ● Genericity, degree of coupling ● Expressive power given to modules Éric Tanter – U.Chile [june | 2005] 30 Part III Reflection and Metaprogramming Éric Tanter – U.Chile [june | 2005] 31 Introduction History and concepts Éric Tanter – U.Chile [june | 2005] 32 Programs and Data ● Distinction data/program ● appears in 1830s, by Charles Babbage ● Difference Engine No.2 ● The store with data and the mill with programs ● 1958, von Neumann ● Architecture of numerical computer ● Idea: store programs in memory, that same where data is stored ● Perspective: a program could alter its own in- structions! Éric Tanter – U.Chile [june | 2005] 33 Programs and Data ● From computing theory ● Lambda calculus (Church) ● Universal Turing Machine ● Metaprogram ● A program that affects a program ● Metaprogramming ● Developing metaprograms Éric Tanter – U.Chile [june | 2005] 34 Reflection ● Philosophy (Brian Cantwell Smith) ● Study on psychology and human experiences ● Foundations of consciousness ● Varieties of self-references ● Varietes of self-descriptions ● Definition of reflection: “A process' integral ability to represent, operate on, and otherwise deal with itself in the same way that it represents, operates on and deals with its primary subject matter” Éric Tanter – U.Chile [june | 2005] 35 Reflection in Computer Science ● Artificial intelligence: self-reasoning systems ● Brian Smith [1982] ● “reflection and semantics in a procedural language” ● 3LISP with Jim Des Rivieres ● Pattie Maes [1987] ● “computational reflection” ● Merging OOP languages and reflective architectures ● Smalltalk, Scheme, Loops, ObjVLisp,... Éric Tanter – U.Chile [june | 2005] 36 Concepts [Maes87] ● Computational System (CS) ● Act and reason about a domain ● Causal connection ● Changes in the domain are reflected in the CS, and vice- versa ● Metasystem ● CS whose domain is another CS ● Reflective system ● Metasystem causally connected to itself Éric Tanter – U.Chile [june | 2005] 37 A Computational System causal connection data reason and act upon world program executer Éric Tanter – U.Chile [june | 2005] 38 A Metasystem data data world program program executer executer metasystem base system Éric Tanter – U.Chile [june | 2005] 39 A Reflective System data world program executer Éric Tanter – U.Chile [june | 2005] 40 Metalevels and towers ●
Recommended publications
  • Lab 7: Floating-Point Addition 0.0

    Lab 7: Floating-Point Addition 0.0

    Lab 7: Floating-Point Addition 0.0 Introduction In this lab, you will write a MIPS assembly language function that performs floating-point addition. You will then run your program using PCSpim (just as you did in Lab 6). For testing, you are provided a program that calls your function to compute the value of the mathematical constant e. For those with no assembly language experience, this will be a long lab, so plan your time accordingly. Background You should be familiar with the IEEE 754 Floating-Point Standard, which is described in Section 3.6 of your book. (Hopefully you have read that section carefully!) Here we will be dealing only with single precision floating- point values, which are formatted as follows (this is also described in the “Floating-Point Representation” subsec- tion of Section 3.6 in your book): Sign Exponent (8 bits) Significand (23 bits) 31 30 29 ... 24 23 22 21 ... 0 Remember that the exponent is biased by 127, which means that an exponent of zero is represented by 127 (01111111). The exponent is not encoded using 2s-complement. The significand is always positive, and the sign bit is kept separately. Note that the actual significand is 24 bits long; the first bit is always a 1 and thus does not need to be stored explicitly. This will be important to remember when you write your function! There are several details of IEEE 754 that you will not have to worry about in this lab. For example, the expo- nents 00000000 and 11111111 are reserved for special purposes that are described in your book (representing zero, denormalized numbers and NaNs).
  • The Hexadecimal Number System and Memory Addressing

    The Hexadecimal Number System and Memory Addressing

    C5537_App C_1107_03/16/2005 APPENDIX C The Hexadecimal Number System and Memory Addressing nderstanding the number system and the coding system that computers use to U store data and communicate with each other is fundamental to understanding how computers work. Early attempts to invent an electronic computing device met with disappointing results as long as inventors tried to use the decimal number sys- tem, with the digits 0–9. Then John Atanasoff proposed using a coding system that expressed everything in terms of different sequences of only two numerals: one repre- sented by the presence of a charge and one represented by the absence of a charge. The numbering system that can be supported by the expression of only two numerals is called base 2, or binary; it was invented by Ada Lovelace many years before, using the numerals 0 and 1. Under Atanasoff’s design, all numbers and other characters would be converted to this binary number system, and all storage, comparisons, and arithmetic would be done using it. Even today, this is one of the basic principles of computers. Every character or number entered into a computer is first converted into a series of 0s and 1s. Many coding schemes and techniques have been invented to manipulate these 0s and 1s, called bits for binary digits. The most widespread binary coding scheme for microcomputers, which is recog- nized as the microcomputer standard, is called ASCII (American Standard Code for Information Interchange). (Appendix B lists the binary code for the basic 127- character set.) In ASCII, each character is assigned an 8-bit code called a byte.
  • The Inheritance Anomaly Revisited

    The Inheritance Anomaly Revisited

    The Inheritance Anomaly Revisited Ryan J. Wisnesky August 2006 Contents Contents i Preface ii Introduction 1 1 The Inheritance Anomaly and Formal Framework 2 1.1 An Overview of the Inheritance Anomaly . 2 1.2 An Overview of the Framework . 4 2 History-based Guard Languages 7 2.1 History-based guard languages . 7 2.2 Two tweaks . 8 2.2.1 The first tweak: Behavior Preservation . 8 2.2.2 The second tweak: Patching the Proof . 10 2.3 Discussion . 13 2.4 Related Work and Future Directions . 13 2.5 Conclusion . 15 3 Intra-object Concurrency 16 3.1 Methods and Messages . 16 3.1.1 New synchronization constructs . 17 3.1.2 Synchronization, Methods, and Messages . 18 3.2 New Types . 19 3.2.1 Mutual Exclusion: TypesS ............................ 20 3.2.2 Mutual Exclusion and Containment: TypesS .................. 24 3.2.3 TypesT,S ...................................... 25 3.3 Conclusion and Related Work . 27 4 Specification Languages 28 5 Overall Conclusion, Future Directions, and a Note on Typing 29 6 Related Work 30 6.1 Core Papers . 30 i 6.2 Concurrent Formal Systems . 31 6.3 Anomaly Avoidance Mechanisms . 33 6.4 Anomaly Generalizations . 36 6.5 Anomaly Experiences . 36 6.6 Surveys . 37 6.7 Aspect-Oriented Programming . 37 6.8 Others............................................ 38 Bibliography 41 ii Introduction The Inheritance Anomaly has been a thorn in the side of the concurrent object-oriented language community for 15 years. Simply put, the anomaly is a failure of inheritance and concurrency to work well with each other, negating the usefulness of inheritance as a mechanism for code-reuse in a concurrent setting.
  • POINTER (IN C/C++) What Is a Pointer?

    POINTER (IN C/C++) What Is a Pointer?

    POINTER (IN C/C++) What is a pointer? Variable in a program is something with a name, the value of which can vary. The way the compiler and linker handles this is that it assigns a specific block of memory within the computer to hold the value of that variable. • The left side is the value in memory. • The right side is the address of that memory Dereferencing: • int bar = *foo_ptr; • *foo_ptr = 42; // set foo to 42 which is also effect bar = 42 • To dereference ted, go to memory address of 1776, the value contain in that is 25 which is what we need. Differences between & and * & is the reference operator and can be read as "address of“ * is the dereference operator and can be read as "value pointed by" A variable referenced with & can be dereferenced with *. • Andy = 25; • Ted = &andy; All expressions below are true: • andy == 25 // true • &andy == 1776 // true • ted == 1776 // true • *ted == 25 // true How to declare pointer? • Type + “*” + name of variable. • Example: int * number; • char * c; • • number or c is a variable is called a pointer variable How to use pointer? • int foo; • int *foo_ptr = &foo; • foo_ptr is declared as a pointer to int. We have initialized it to point to foo. • foo occupies some memory. Its location in memory is called its address. &foo is the address of foo Assignment and pointer: • int *foo_pr = 5; // wrong • int foo = 5; • int *foo_pr = &foo; // correct way Change the pointer to the next memory block: • int foo = 5; • int *foo_pr = &foo; • foo_pr ++; Pointer arithmetics • char *mychar; // sizeof 1 byte • short *myshort; // sizeof 2 bytes • long *mylong; // sizeof 4 byts • mychar++; // increase by 1 byte • myshort++; // increase by 2 bytes • mylong++; // increase by 4 bytes Increase pointer is different from increase the dereference • *P++; // unary operation: go to the address of the pointer then increase its address and return a value • (*P)++; // get the value from the address of p then increase the value by 1 Arrays: • int array[] = {45,46,47}; • we can call the first element in the array by saying: *array or array[0].
  • Subtyping Recursive Types

    Subtyping Recursive Types

    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
  • Attachment A

    Attachment A

    Board of Governors, State University System of Florida Request to Offer a New Degree Program (Please do not revise this proposal format without prior approval from Board staff) University of West Florida Fall 2018 University Submitting Proposal Proposed Implementation Term Hal Marcus College of Science and Engineering Computer Science Name of College(s) or School(s) Name of Department(s)/ Division(s) Bachelor of Science in Computer Computer Science Science Academic Specialty or Field Complete Name of Degree 11.0701 Proposed CIP Code The submission of this proposal constitutes a commitment by the university that, if the proposal is approved, the necessary financial resources and the criteria for establishing new programs have been met prior to the initiation of the program. Date Approved by the University Board of President Date Trustees Signature of Chair, Board of Date Provost and Senior Vice Date Trustees President Provide headcount (HC) and full-time equivalent (FTE) student estimates of majors for Years 1 through 5. HC and FTE estimates should be identical to those in Table 1 in Appendix A. Indicate the program costs for the first and the fifth years of implementation as shown in the appropriate columns in Table 2 in Appendix A. Calculate an Educational and General (E&G) cost per FTE for Years 1 and 5 (Total E&G divided by FTE). Projected Implementation Projected Program Costs Enrollment Timeframe (From Table 2) (From Table 1) E&G Contract E&G Auxiliary Total HC FTE Cost per & Grants Funds Funds Cost FTE Funds Year 1 150 96.87 3,241 313,960 0 0 313,960 Year 2 150 96.87 Year 3 160 103.33 Year 4 160 103.33 Year 5 170 109.79 3,426 376,087 0 0 376,087 1 Note: This outline and the questions pertaining to each section must be reproduced within the body of the proposal to ensure that all sections have been satisfactorily addressed.
  • The Circle Meta-Model

    The Circle Meta-Model

    Document:P2062R0 Revises: (original) Date: 01-11-2020 Audience: SG7 Authors: Wyatt Childers ([email protected]) ​ ​ Andrew Sutton ([email protected]) ​ ​ Faisal Vali ([email protected]) Daveed Vandevoorde ([email protected]) The Circle Meta-model Introduction During the November 2019 meeting in Belfast, some of the SG7 participants enthusiastically mentioned Circle1 as providing a more intuitive compile-time programming model and suggested that SG7 investigate overhauling the de-facto SG7 approach (P1240+P17332) to follow Circle's ​ ​ ​ general approach (to reflection and metaprogramming). This paper describes a framework for understanding metaprogramming systems and provides a high-level overview of some of Circle's main characteristics, contrasting them to P1240's ​ ​ approach augmented with an injection mechanism along the lines of P1717. ​ ​ While we appreciate some of Circle’s powerful capabilities, we also raise some concerns with its underlying model and provide arguments in support of P1240’s choices as being a more ​ ​ suitable fit for C++’s evolution. The Dimensions of Reflective Programming In P0633, we identified three “dimensions” of compile-time reflective metaprogramming: ​ ​ 1. Control: How are compile-time computations effected/interpreted? What are metaprograms? 2. Reflection: How are source constructs are made available as data for use in metaprograms? 3. Synthesis: How can “code” be generated from a programmatic representation? 1 https://www.circle-lang.org/ Circle is an impressive project: Sean Baxter developed a brand new ​ ​ C++17-like front end on top of LLVM, incorporating a variety of new compile-time capabilities that align closely with SG7's goals. For Sean’s motivations, see https://github.com/seanbaxter/circle/blob/master/examples/README.md#why-i-wrote-circle.
  • Comparative Studies of Programming Languages; Course Lecture Notes

    Comparative Studies of Programming Languages; Course Lecture Notes

    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
  • Sub-Method Structural and Behavioral Reflection Marcus Denker

    Sub-Method Structural and Behavioral Reflection Marcus Denker

    Sub-method Structural and Behavioral Reflection Marcus Denker To cite this version: Marcus Denker. Sub-method Structural and Behavioral Reflection. Computer Science [cs]. Universität Bern, 2008. English. tel-00555937 HAL Id: tel-00555937 https://tel.archives-ouvertes.fr/tel-00555937 Submitted on 14 Jan 2011 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Sub-method Structural and Behavioral Reflection Inauguraldissertation der Philosophisch-naturwissenschaftlichen Fakultät der Universität Bern vorgelegt von Marcus Denker von Deutschland Leiter der Arbeit: Prof. Dr. O. Nierstrasz Institut für Informatik und angewandte Mathematik Von der Philosophisch-naturwissenschaftlichen Fakultät angenommen. Bern, 26.05.2008 Der Dekan: Prof. Dr. P. Messerli This dissertation is available as a free download from http://scg.unibe.ch Copyright © 2008 Marcus Denker. The contents of this dissertation are protected under Creative Commons Attribution-ShareAlike 3.0 Unported license. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).
  • A Variable Precision Hardware Acceleration for Scientific Computing Andrea Bocco

    A Variable Precision Hardware Acceleration for Scientific Computing Andrea Bocco

    A variable precision hardware acceleration for scientific computing Andrea Bocco To cite this version: Andrea Bocco. A variable precision hardware acceleration for scientific computing. Discrete Mathe- matics [cs.DM]. Université de Lyon, 2020. English. NNT : 2020LYSEI065. tel-03102749 HAL Id: tel-03102749 https://tel.archives-ouvertes.fr/tel-03102749 Submitted on 7 Jan 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N°d’ordre NNT : 2020LYSEI065 THÈSE de DOCTORAT DE L’UNIVERSITÉ DE LYON Opérée au sein de : CEA Grenoble Ecole Doctorale InfoMaths EDA N17° 512 (Informatique Mathématique) Spécialité de doctorat :Informatique Soutenue publiquement le 29/07/2020, par : Andrea Bocco A variable precision hardware acceleration for scientific computing Devant le jury composé de : Frédéric Pétrot Président et Rapporteur Professeur des Universités, TIMA, Grenoble, France Marc Dumas Rapporteur Professeur des Universités, École Normale Supérieure de Lyon, France Nathalie Revol Examinatrice Docteure, École Normale Supérieure de Lyon, France Fabrizio Ferrandi Examinateur Professeur associé, Politecnico di Milano, Italie Florent de Dinechin Directeur de thèse Professeur des Universités, INSA Lyon, France Yves Durand Co-directeur de thèse Docteur, CEA Grenoble, France Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2020LYSEI065/these.pdf © [A.
  • The Inheritance Anomaly: Ten Years After

    The Inheritance Anomaly: Ten Years After

    The inheritance anomaly: ten years after Giuseppe Milicia Vladimiro Sassone Chi Spaces Technologies ltd. University of Sussex, UK Cambridge, UK [email protected] [email protected] ABSTRACT Clearly we must make sure that no object is removed from an The term inheritance anomaly was coined in 1993 by Matsuoka empty buffer and that no object is inserted into a full buffer. In a and Yonezawa [15] to refer to the problems arising by the coexis- sequential setting, the burden of ensuring such constraints resides tence of inheritance and concurrency in concurrent object oriented with the buffer’s user. Indeed the buffer is created and used by languages (COOLs). The quirks arising by such combination have one thread only, which is responsible for the state of the object. been observed since the early eighties, when the first experimen- To facilitate usage, the buffer’s methods might return certain er- tal COOLs were designed [3]. In the nineties COOLs turned from ror codes in case of misuse. This approach is not feasible in a research topic to widely used tools in the everyday programming concurrent setting. The buffer will be used concurrently by mul- practice, see e.g. the Java [9] experience. This expository paper ex- tiple clients, leaving each of them no idea on the buffer’s current tends the survey presented in [15] to account for new and widely state. Although it is possible to envisage ad-hoc protocols among used COOLs, most notably Java and C] [19]. Specifically, we il- clients to keep track of the buffer’s state, such a solution is com- lustrate some innovative approaches to COOL design relying on plex and hardly feasible in practice.
  • Advanced-Java.Pdf

    Advanced-Java.Pdf

    Advanced java i Advanced java Advanced java ii Contents 1 How to create and destroy objects 1 1.1 Introduction......................................................1 1.2 Instance Construction.................................................1 1.2.1 Implicit (Generated) Constructor.......................................1 1.2.2 Constructors without Arguments.......................................1 1.2.3 Constructors with Arguments........................................2 1.2.4 Initialization Blocks.............................................2 1.2.5 Construction guarantee............................................3 1.2.6 Visibility...................................................4 1.2.7 Garbage collection..............................................4 1.2.8 Finalizers...................................................5 1.3 Static initialization..................................................5 1.4 Construction Patterns.................................................5 1.4.1 Singleton...................................................6 1.4.2 Utility/Helper Class.............................................7 1.4.3 Factory....................................................7 1.4.4 Dependency Injection............................................8 1.5 Download the Source Code..............................................9 1.6 What’s next......................................................9 2 Using methods common to all objects 10 2.1 Introduction...................................................... 10 2.2 Methods equals and hashCode...........................................