DOCSLIB.ORG

Jamaicavm 8.1 — User Manual

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

JamaicaVM 8.1 — User Manual Java Technology for Critical Embedded Systems aicas GmbH 2 JamaicaVM 8.1 — User Manual: Java Technology for Critical Embedded Systems JamaicaVM 8.1, Release 1. Published May 31, 2017. c 2001–2017 aicas GmbH, Karlsruhe. All rights reserved. No licenses, expressed or implied, are granted with respect to any of the technology described in this publication. aicas GmbH retains all intellectual property rights associated with the technology described in this publication. This publication is intended to assist application developers to develop applications only for the Jamaica Virtual Machine. Every effort has been made to ensure that the information in this publication is accurate. aicas GmbH is not responsible for printing or clerical errors. Although the information herein is provided with good faith, the supplier gives neither warranty nor guarantee that the information is correct or that the results described are obtainable under end-user conditions. aicas GmbH phone +49 721 663 968-0 Emmy-Noether-Straße 9 fax +49 721 663 968-99 76131 Karlsruhe email [email protected] Germany web http://www.aicas.com aicas incorporated phone +1 203 359 5705 6 Landmark Square, Suite 400 Stamford CT 06901 email [email protected] USA web http://www.aicas.com aicas GmbH phone +33 1 4997 1762 9 Allee de l’Arche fax +33 1 4997 1700 92671 Paris La Defense email [email protected] France web http://www.aicas.com This product includes software developed by IAIK of Graz University of Technology. This software is based in part on the work of the Independent JPEG Group. Java and all Java-based trademarks are registered trademarks of Oracle America, Inc. All other brands or product names are trademarks or registered trademarks of their respective holders. ALL IMPLIED WARRANTIES ON THIS PUBLICATION, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF THE ORIGINAL RETAIL PURCHASE OF THIS PRODUCT. Although aicas GmbH has reviewed this publication, aicas GmbH MAKES NO WARRANTY OR REPRESENTATION, EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THIS PUBLICATION, ITS QUALITY, ACCURACY, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS PUBLICATION IS PROVIDED AS IS, AND YOU, THE PURCHASER, ARE ASSUMING THE ENTIRE RISK AS TO ITS QUALITY AND ACCURACY. IN NO EVENT WILL aicas GmbH BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS PUBLICATION, even if advised of the possibility of such damages. THE WARRANTIES SET FORTH ABOVE ARE EXCLUSIVE AND IN LIEU OF ALL OTHERS, ORAL OR WRITTEN, EXPRESSED OR IMPLIED. Contents Preface 13 Intended Audience of This Book . 13 Contacting aicas . 14 What is New in JamaicaVM 8.1 . 14 What is New in JamaicaVM 8.0 . 15 I Introduction 17 1 Key Features of JamaicaVM 19 1.1 Hard Realtime Execution Guarantees . 19 1.2 Real-Time Specification for Java support . 20 1.3 Minimal footprint . 20 1.4 ROMable code . 21 1.5 Native code support . 21 1.6 Dynamic Linking . 21 1.7 Supported Platforms . 21 1.7.1 Development platforms . 21 1.7.2 Target platforms . 22 1.8 Fast Execution . 23 1.9 Tools for Realtime and Embedded System Development . 24 2 Getting Started 25 2.1 Installation of JamaicaVM . 25 2.1.1 Linux . 26 2.1.2 Sun/Solaris . 28 2.1.3 Windows . 28 2.2 Installation of License Keys . 28 2.2.1 Using the Standard Edition . 29 2.2.2 Using the Personal Edition . 29 2.3 JamaicaVM Directory Structure . 30 3 4 CONTENTS 2.3.1 API Specification . 30 2.3.2 Target Platforms . 30 2.4 Building and Running an Example Java Program . 32 2.4.1 Host Platform . 32 2.4.2 Target Platform . 34 2.4.3 Improving Size and Performance . 34 2.4.4 Overview of Further Examples . 35 2.5 Notations and Conventions . 35 2.5.1 Typographic Conventions . 36 2.5.2 Argument Syntax . 36 2.5.3 Jamaica Home and User Home . 37 3 Tools Overview 39 3.1 Jamaica Java Compiler . 39 3.2 Jamaica Virtual Machine . 39 3.3 Creating Target Executables . 40 3.4 Accelerating JAR Files . 41 3.5 Monitoring Realtime Behavior . 41 4 Support for the Eclipse IDE 43 4.1 Plug-in installation . 43 4.1.1 Installation on Eclipse . 43 4.1.2 Installation on Other IDEs . 44 4.2 Setting up JamaicaVM Distributions . 44 4.3 Using JamaicaVM in Java Projects . 45 4.4 Setting Virtual Machine Parameters . 45 4.5 Building applications with Jamaica Builder . 45 4.5.1 Getting started . 46 4.5.2 Jamaica Buildfiles . 46 II Tools Usage and Guidelines 49 5 Performance Optimization 51 5.1 Creating a profile . 51 5.1.1 Creating a profiling application . 52 5.1.2 Using the profiling VM . 53 5.1.3 Dumping a profile via network . 53 5.1.4 Creating a micro profile . 54 5.2 Using a profile with the Builder . 54 5.2.1 Building with a profile . 55 CONTENTS 5 5.2.2 Building with multiple profiles . 55 5.3 Interpreting the profiling output . 56 5.3.1 Format of the profile file . 56 5.3.2 Example . 60 6 Reducing Footprint and Memory Usage 63 6.1 Compilation . 63 6.1.1 Suppressing Compilation . 63 6.1.2 Using Default Compilation . 65 6.1.3 Using a Custom Profile . 66 6.1.4 Code Optimization by the C Compiler . 68 6.1.5 Full Compilation . 69 6.2 Smart Linking . 70 6.3 API Library Classes and Resources . 72 6.4 RAM Usage . 73 6.4.1 Measuring RAM Demand . 73 6.4.2 Memory Required for Threads . 75 6.4.3 Memory Required for Line Numbers . 79 7 Memory Management Configuration 83 7.1 Configuration for soft-realtime applications . 83 7.1.1 Initial heap size . 83 7.1.2 Maximum heap size . 84 7.1.3 Finalizer thread priority . 84 7.1.4 Reference Handler thread priority . 85 7.1.5 Reserved memory . 85 7.1.6 Stop-the-world Garbage Collection . 87 7.1.7 Recommendations . 87 7.2 Configuration for hard-realtime applications . 88 7.2.1 Usage of the Memory Analyzer tool . 88 7.2.2 Measuring an application’s memory requirements . 88 7.2.3 Fine tuning the final executable application . 90 7.2.4 Constant Garbage Collection Work . 92 7.2.5 Comparing dynamic mode and constant GC work mode . 93 7.2.6 Determination of the worst case execution time of an al- location . 94 7.2.7 Examples . 94 8 Debugging Support 97 8.1 Enabling the Debugger Agent . 97 8.2 Connecting to Jamaica from the Command Line . 98 6 CONTENTS 8.2.1 Using sockets as transport layer . 98 8.2.2 Using shared memory as transport layer . 99 8.3 Configuring the IDE to connect to Jamaica . 99 8.4 Reference Information . 101 9 The Real-Time Specification for Java 103 9.1 Realtime programming with the RTSJ . 103 9.1.1 Thread Scheduling . 104 9.1.2 Memory Management . 104 9.1.3 Synchronization . 104 9.1.4 Example . 105 9.2 Realtime Garbage Collection . 106 9.3 Relaxations in JamaicaVM . 106 9.3.1 Use of Memory Areas . 107 9.3.2 Thread Priorities . 107 9.3.3 Runtime checks for NoHeapRealtimeThread . 107 9.3.4 Static Initializers . 107 9.3.5 Class PhysicalMemoryManager . 108 9.4 Limitations of RTSJ Implementation . 108 9.5 Computational Transparency . 109 9.5.1 Efficient Java Statements . 110 9.5.2 Non-Obvious Slightly Inefficient Constructs . 112 9.5.3 Statements Causing Implicit Memory Allocation . 112 9.5.4 Operations Causing Class Initialization . 115 9.5.5 Operations Causing Class Loading . 116 9.6 Supported Standards . 117 9.6.1 Real-Time Specification for Java . 117 9.6.2 Java Native Interface . 119 9.7 Memory Management . 120 9.7.1 Memory Management of RTSJ . 121 9.7.2 Finalizers . 122 9.7.3 Configuring a Realtime Garbage Collector . 123 9.7.4 Programming with the RTSJ and Realtime Garbage Col- lection . 124 9.7.5 Memory Management Guidelines . 125 9.8 Scheduling and Synchronization . 126 9.8.1 Schedulable Entities . 126 9.8.2 Synchronization . 128 9.8.3 Scheduling Policy and Priorities . 131 9.9 Libraries . 134 9.10 Summary . 134 CONTENTS 7 9.10.1 Efficiency . 135 9.10.2 Memory Allocation . 135 9.10.3 EventHandlers ..
Recommended publications
  • Ben Livshits 1 Basic Instrumentation

    Ben Livshits 1 Basic Instrumentation

    Runtime monitoring CO444H Ben Livshits 1 Basic Instrumentation • Insert additional code into the program • This code is designed to record important events as they occur at runtime • Some examples • A particular function is being hit or a statement is being hit • This leads to function-level or line-level coverage • Each allocation to measure overall memory allocation 2 Levels of Instrumentation • Native code • Instrument machine code • Tools like LLVM are often used for rewriting • Bytecode • Common for languages such as Java and C# • A variety of tools are available for each bytecode format • JoeQ is in this category as well, although it’s a lot more general • Source code • Common for languages like JavaScript • Often the easiest option – parse the code and add more statements 3 Runtime Code Monitoring •Three major examples of monitoring • Purify/Valgrind • Detecting data races • Detecting memory leaks 4 5 Memory Error Detection Purify • C and C++ are not type-safe • The type system and the runtime fail to enforce type safety • What are some of the examples? • Possible to read and write outside of your intended data structures • Write beyond loop bounds • Or object bounds • Or overwrite the code pointer, etc. 6 Track Each Byte of Memory • Three states for every byte of tracker memory • Unallocated: cannot be read or written • Allocated but not initialized: cannot be read • Allocated and initialized: all operations are allowed 7 Instrumentation for Purify • Check the state of each byte at every access • Binary instrumentation: • Add
  • Memory Leak Or Dangling Pointer

    Memory Leak Or Dangling Pointer

    Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer.
  • Effective and Efficient Memory Protection Using Dynamic Tainting

    Effective and Efficient Memory Protection Using Dynamic Tainting

    1 Effective and Efficient Memory Protection Using Dynamic Tainting Ioannis Doudalis, Student Member, IEEE, James Clause, Member, IEEE, Guru Venkataramani, Member, IEEE, Milos Prvulovic, Senior Member, IEEE, and Alessandro Orso, Member, IEEE, ! Abstract—Programs written in languages allowing direct access to pointer p or a pointer derived from p and 2) if the access memory through pointers often contain memory-related faults, which occurs during the interval when p is valid, (i.e. between the cause non-deterministic failures and security vulnerabilities. We present allocation and deallocation of m). All other accesses to m are a new dynamic tainting technique to detect illegal memory accesses. illegal memory accesses (IMAs), where a pointer is used to When memory is allocated, at runtime, we taint both the memory and the corresponding pointer using the same taint mark. Taint marks access memory outside the bounds of the memory area with are then propagated and checked every time a memory address m which it was originally associated, or outside the time period is accessed through a pointer p; if the associated taint marks differ, during which the pointer is valid. an illegal access is reported. To allow always-on checking using a IMAs are especially relevant for several reasons. First, they low-overhead, hardware-assisted implementation, we make several key are caused by typical programming errors, such as array-out- technical decisions. We use a configurable, low number of reusable taint of-bounds accesses and stale pointer dereferences, and are thus marks instead of a unique mark for each allocated area of memory, reducing the performance overhead without losing the ability to target widespread and common.
  • An OSEK/VDX-Based Multi-JVM for Automotive Appliances

    An OSEK/VDX-Based Multi-JVM for Automotive Appliances

    AN OSEK/VDX-BASED MULTI-JVM FOR AUTOMOTIVE APPLIANCES Christian Wawersich, Michael Stilkerich, Wolfgang Schr¨oder-Preikschat University of Erlangen-Nuremberg Distributed Systems and Operating Systems Erlangen, Germany E-Mail: [email protected], [email protected], [email protected] Abstract: The automotive industry has recent ambitions to integrate multiple applications from different micro controllers on a single, more powerful micro controller. The outcome of this integration process is the loss of the physical isolation and a more complex monolithic software. Memory protection mechanisms need to be provided that allow for a safe co-existence of heterogeneous software from different vendors on the same hardware, in order to prevent the spreading of an error to the other applications on the controller and leaving an unclear responsi- bility situation. With our prototype system KESO, we present a Java-based solution for ro- bust and safe embedded real-time systems that does not require any hardware protection mechanisms. Based on an OSEK/VDX operating system, we offer a familiar system creation process to developers of embedded software and also provide the key benefits of Java to the embedded world. To the best of our knowledge, we present the first Multi-JVM for OSEK/VDX operating systems. We report on our experiences in integrating Java and an em- bedded operating system with focus on the footprint and the real-time capabili- ties of the system. Keywords: Java, Embedded Real-Time Systems, Automotive, Isolation, KESO 1. INTRODUCTION Modern cars contain a multitude of micro controllers for a wide area of tasks, ranging from convenience features such as the supervision of the car’s audio system to safety relevant functions such as assisting the braking system of the car.
  • Tutorial on Debugging, Memory Leaks and Profiling

    Tutorial on Debugging, Memory Leaks and Profiling

    High Performance Computing for Science and Engineering I Tutorial on debugging, memory leaks and profiling Michalis Chatzimanolakis Computational Science & Engineering Laboratory OUTLINE - Approaches to debug your code •Using assertions •Using a debugger •Memory sanitation •Using a profiler Assertions in C++ An assertion is a logical statement that will cause your code to abort execution, if it is false. Example: Assertions can affect performance, Assertions perform checks that make sure that as they are essentially ‘if’ statements. some conditions are met. However, it is good practice to add assertions in a code. A simple compilation flag can ignore all assertions, so it is generally a good idea to use them. It is useful to combine assertions with the std functions isinf and isnan They can also be used with screen output. Compiler warnings Compiler warnings are compilation flags that you can (should) add to your Makefiles. Enabling warnings makes the compiler check for several issues in your source file, such as: • Forgetting to initialize a variable • Not using a declared variable • Using a function before declaring it • Having screen/file output with incorrect format (for example, treating doubles as integers) Generally, you should add warnings and try to fix all of them, before proceeding with further debugging your code. Note that different compilers may produce different warnings. The most common compiler warning flags are listed below: -Wall : enables several construction/declaration warnings -Wextra : more warnings than Wall including warnings for unused variables -Werror: will treat all warnings as errors -Wpedantic: warnings related to the use of non standard C++ extensions Using a debugger What is a debugger? A debugger is a program.
  • Memory Vulnerability Diagnosis for Binary Program

    Memory Vulnerability Diagnosis for Binary Program

    ITM Web of Conferences 7 03004 , (2016) DOI: 10.1051/itmconf/20160703004 ITA 2016 Memory Vulnerability Diagnosis for Binary Program Feng-Yi TANG, Chao FENG and Chao-Jing TANG College of Electronic Science and Engineering National University of Defense Technology Changsha, China Abstract. Vulnerability diagnosis is important for program security analysis. It is a further step to understand the vulnerability after it is detected, as well as a preparatory step for vulnerability repair or exploitation. This paper mainly analyses the inner theories of major memory vulnerabilities and the threats of them. And then suggests some methods to diagnose several types of memory vulnerabilities for the binary programs, which is a difficult task due to the lack of source code. The diagnosis methods target at buffer overflow, use after free (UAF) and format string vulnerabilities. We carried out some tests on the Linux platform to validate the effectiveness of the diagnosis methods. It is proved that the methods can judge the type of the vulnerability given a binary program. 1 Introduction (or both) the memory area. These headers can contain some information like size, used or not, and etc. Memory vulnerabilities are difficult to detect and diagnose Therefore, we can monitor the allocator so as to especially for those do not crash the program. Due to its determine the base address and the size of the allocation importance, vulnerability diagnosis problem has been areas. Then, check all STORE and LOAD accesses in intensively studied. Researchers have proposed different memory to see which one is outside the allocated area. techniques to diagnose memory vulnerabilities.
  • A Statistical Approach for Identifying Memory Leaks in Cloud Applications

    A Statistical Approach for Identifying Memory Leaks in Cloud Applications

    A STATISTICAL APPROACH FOR IDENTIFYING MEMORY LEAKS IN CLOUD APPLICATIONS Vladimir Sorˇ and Satish Narayana Srirama Institute of Computer Science, University of Tartu, J. Liivi 2, Tartu, Estonia Keywords: Troubleshooting, JavaTM Virtual Machine, Byte code instrumentation, Cloud computing, Tools. Abstract: This position paper describes the attempt to automate the statistical approach for memory leak detection in JavaTM applications. Proposed system extends the basic statistical memory leak detection method with further intelligence to pinpoint the source of the memory leak in the source code. As the method adds only small overhead in runtime it is designed to be used in production systems and will help detecting memory leaks in production environments without constraint to the source of the leak. Architecture of the proposed approach is intended to use in cloud applications. 1 INTRODUCTION in production under very specific circumstances (of- ten hardly specifiable) can be very hard to find and fix Memory leaks can be a major problem in distributed in development and test environments. applications, depleting their performance, even if they This is the area we think we can improve by de- run on platforms with automatic memory manage- veloping the solution that uses efficient statistical al- ment like Java Virtual Machine. Finding memory gorithm to detect memory leaks in advance, imposes leaks is coveredby many researches and there are sev- low overhead in production system and would help eral tools and methodologies to find memory leaks. tracking down the source of the leak. The rest of the However, these tools are incorporated in profilers and paper is organized as follows.
  • Secure Control Applications in Smart Homes and Buildings

    Secure Control Applications in Smart Homes and Buildings

    Die approbierte Originalversion dieser Dissertation ist in der Hauptbibliothek der Technischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Secure Control Applications in Smart Homes and Buildings DISSERTATION submitted in partial fulfillment of the requirements for the degree of Doktor der Technischen Wissenschaften by Mag. Dipl.-Ing. Friedrich Praus Registration Number 0025854 to the Faculty of Informatics at the Vienna University of Technology Advisor: Ao.Univ.Prof. Dipl.-Ing. Dr.techn. Wolfgang Kastner The dissertation has been reviewed by: Ao.Univ.Prof. Dipl.-Ing. Prof. Dr. Peter Palensky Dr.techn. Wolfgang Kastner Vienna, 1st October, 2015 Mag. Dipl.-Ing. Friedrich Praus Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Mag. Dipl.-Ing. Friedrich Praus Hallergasse 11/29, A-1110 Wien Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 1. Oktober 2015 Friedrich Praus v Kurzfassung Die zunehmende Integration von heterogenen Gebäudeautomationssystemen ermöglicht gesteigerten Komfort, Energieeffizienz, verbessertes Gebäudemanagement, Nachhaltig- keit sowie erweiterte Anwendungsgebiete, wie beispielsweise “Active Assisted Living” Szenarien. Diese Smart Homes und Gebäude sind heutzutage als dezentrale Systeme rea- lisiert, in denen eingebettete Geräte Prozessdaten über ein Netzwerk austauschen.
  • Using Cyclic Memory Allocation to Eliminate Memory Leaks

    Using Cyclic Memory Allocation to Eliminate Memory Leaks

    Using Cyclic Memory Allocation to Eliminate Memory Leaks Huu Hai NGUYEN1 and Martin RINARD2 1Singapore-MIT Alliance, National University of Singapore 2CSAIL, Massachusetts Institute of Technology Abstract— We present and evaluate a new memory man- I. INTRODUCTION agement technique for eliminating memory leaks in programs with dynamic memory allocation. This technique observes the A program that uses explicit allocation and deallocation has execution of the program on a sequence of training inputs to a memory leak when it fails to free objects that it will no longer find m-bounded allocation sites, which have the property that at access in the future. A program that uses garbage collection any time during the execution of the program, the program only has a memory leak when it retains references to objects that accesses the last m objects allocated at that site. The technique it will no longer access in the future. Memory leaks are an then transforms the program to use cyclic memory allocation at that site: it preallocates a buffer containing m objects of the issue since they can cause the program to consume increasing type allocated at that site, with each allocation returning the amounts of memory as it runs. Eventually the program may next object in the buffer. At the end of the buffer the allocations exhaust the available memory and fail. Memory leaks may wrap back around to the first object. Cyclic allocation eliminates therefore be especially problematic for server programs that any memory leak at the allocation site — the total amount of must execute for long (and in principle unbounded) periods of memory required to hold all of the objects ever allocated at the site is simply m times the object size.
  • Android Cours 1 : Introduction `Aandroid / Android Studio

    Android Cours 1 : Introduction `Aandroid / Android Studio

    Android Cours 1 : Introduction `aAndroid / Android Studio Damien MASSON [email protected] http://www.esiee.fr/~massond 21 f´evrier2017 R´ef´erences https://developer.android.com (Incontournable !) https://openclassrooms.com/courses/ creez-des-applications-pour-android/ Un tutoriel en fran¸caisassez complet et plut^ot`ajour... 2/52 Qu'est-ce qu'Android ? PME am´ericaine,Android Incorporated, cr´e´eeen 2003, rachet´eepar Google en 2005 OS lanc´een 2007 En 2015, Android est le syst`emed'exploitation mobile le plus utilis´edans le monde (>80%) 3/52 Qu'est-ce qu'Android ? Cinq couches distinctes : 1 le noyau Linux avec les pilotes ; 2 des biblioth`equeslogicielles telles que WebKit/Blink, OpenGL ES, SQLite ou FreeType ; 3 un environnement d'ex´ecutionet des biblioth`equespermettant d'ex´ecuterdes programmes pr´evuspour la plate-forme Java ; 4 un framework { kit de d´eveloppement d'applications ; 4/52 Android et la plateforme Java Jusqu'`asa version 4.4, Android comporte une machine virtuelle nomm´eeDalvik Le bytecode de Dalvik est diff´erentde celui de la machine virtuelle Java de Oracle (JVM) le processus de construction d'une application est diff´erent Code Java (.java) ! bytecode Java (.class/.jar) ! bytecode Dalvik (.dex) ! interpr´et´e L'ensemble de la biblioth`equestandard d'Android ressemble `a J2SE (Java Standard Edition) de la plateforme Java. La principale diff´erenceest que les biblioth`equesd'interface graphique AWT et Swing sont remplac´eespar des biblioth`equesd'Android. 5/52 Android Runtime (ART) A` partir de la version 5.0 (2014), l'environnement d'ex´ecution ART (Android RunTime) remplace la machine virtuelle Dalvik.
  • Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D

    Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D

    VU Research Portal Efficient High Frequency Checkpointing for Recovery and Debugging Vogt, D. 2019 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Vogt, D. (2019). Efficient High Frequency Checkpointing for Recovery and Debugging. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 30. Sep. 2021 Efficient High Frequency Checkpointing for Recovery and Debugging Ph.D. Thesis Dirk Vogt Vrije Universiteit Amsterdam, 2019 This research was funded by the European Research Council under the ERC Advanced Grant 227874. Copyright © 2019 by Dirk Vogt ISBN 978-94-028-1388-3 Printed by Ipskamp Printing BV VRIJE UNIVERSITEIT Efficient High Frequency Checkpointing for Recovery and Debugging ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr.
  • Partner Directory Wind River Partner Program

    Partner Directory Wind River Partner Program

    PARTNER DIRECTORY WIND RIVER PARTNER PROGRAM The Internet of Things (IoT), cloud computing, and Network Functions Virtualization are but some of the market forces at play today. These forces impact Wind River® customers in markets ranging from aerospace and defense to consumer, networking to automotive, and industrial to medical. The Wind River® edge-to-cloud portfolio of products is ideally suited to address the emerging needs of IoT, from the secure and managed intelligent devices at the edge to the gateway, into the critical network infrastructure, and up into the cloud. Wind River offers cross-architecture support. We are proud to partner with leading companies across various industries to help our mutual customers ease integration challenges; shorten development times; and provide greater functionality to their devices, systems, and networks for building IoT. With more than 200 members and still growing, Wind River has one of the embedded software industry’s largest ecosystems to complement its comprehensive portfolio. Please use this guide as a resource to identify companies that can help with your development across markets. For updates, browse our online Partner Directory. 2 | Partner Program Guide MARKET FOCUS For an alphabetical listing of all members of the *Clavister ..................................................37 Wind River Partner Program, please see the Cloudera ...................................................37 Partner Index on page 139. *Dell ..........................................................45 *EnterpriseWeb