DOCSLIB.ORG

Challenges and Solutions in the Design of a Java Virtual Machine for Resource Constrained Microcontrollers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Challenges and Solutions in the Design of a Java Virtual Machine for Resource Constrained Microcontrollers Challenges and Solutions in the Design of a Java Virtual Machine for Resource Constrained Microcontrollers Faisal Aslam Dissertation Submitted to the University of Freiburg for Doctorate Degree in Computer Scinece Computer Networks and Telematics Department of Computer Science Faculty of Applied Sciences University of Freiburg, Germany March 2011 Dissertation Defense Date: 17.03.2011 Thesis committee: Chair: Prof. Dr. Georg Lausen Examiner: PD Dr. Cyrill Stachniss Referees: Prof. Dr. Christian Schindelhauer Prof. Dr. Peter Thiemann To Abbu, Ammi and Ayesha Zusammenfassung Diese Arbeit beschreibt die TakaTuka Java Virtual Machine (JVM), die für Microcon- troller mit geringen Kapazitäten an RAM, Speicher und Prozessor entwickelt wurde. TakaTuka optimiert die Speicheranforderungen sowohl des compilierten Java Codes als auch die des JVM Interpreters, die beide auf einem eingebetteten System abgespeichert werden müssen. Im Durchschnitt lässt sich die Größe des compilierten Java Codes der TakaTuka JVM um über 92% der Größe des Standard-Java-Codes eines Programms re- duzieren. Desweiteren kann die Interpreter-Größe für ein gegebenes Programm auf nicht mehr als 25 KB verkleinert werden. Auf diese Weise führt ein Sensorknoten mit geringem Flash Speicher einen hoch optimierten Java Binärcode und Java Interpreter aus. Die Fähigkeit komplexe Java-Programme auszuführen, wird durch den auf den Bauteilen vorhandenen RAM-Speicher beschränkt. Das Speicher-Management für ein Java Pro- gramm besteht aus zwei Teilen: Erstens wird der Speicher, den jedes Objekt konsumiert, durch die Garbage Collection (GC) geregelt, die zwischendurch ausgeführt wird um Spe- icher wieder freizugeben. Zweitens wird der Speicher, den der Frame einer Funktion beansprucht hat, automatisch zurückgefordert, sobald eine aufgerufene Funktion been- det ist. TakaTuka verfügt über eine Offline Garbage Collection, um den von Objekten während der Dauer einer Programmausführung beanspruchten Speicher zu reduzieren. Die Offline Garbage Collection erlaubt die Freigabe eines Objekts, das zwar noch erreich- bar ist, aber allerdings garantiert nicht mehr im Programm benutzt wird. Es wird gezeigt, dass die Offline GC den RAM-Speicher, das dem Programm zur Verfügung steht, im Ver- gleich zum üblichen online Garbage Collector um bis zu 66% erhöhen kann. Eine weitere wichtige Eigenschaft der TakaTuka JVM ist das Variable Slot Size (VSS) Schema, das die RAM Anforderungen an den Funktionen-Frame verringert. Die durch TakaTuka bereit gestellten Speicher- und RAM-Optimierungen erhöhen außer- dem die Ausführungsgeschwindigkeit eines Programms und erhöht auf diese Weise die Lebensdauer eines Sensorknotens. Die Eigenschaften der TakaTuka JVM bezüglich Spe- icher, Leistungs und RAM-Konsum machen sie zu einer attraktiven Plattform, um An- wendungen für drahtlose Sensornetzwerke zu entwickeln, die Microcontroller und einge- bettete Systeme beinhalten. v Abstract This thesis describes the TakaTuka Java virtual machine (JVM), which has been devel- oped for microcontrollers with small RAM, storage and processing power. The TakaTuka optimizes storage requirements for the Java binary as well as the JVM interpreter, both of which are to be stored on an embedded device. On the average, Java binary size of the TakaTuka JVM can have a percentage reduction of more than 92 % of the size of tra- ditional Java binary of a program. Furthermore, the interpreter size for a given program may be reduced to as small as 25 KB. Thus a mote with small flash storage executes a highly optimized Java binary and Java interpreter. The ability of tiny motes to run large, feature-rich Java programs is constrained by the amount of RAM installed on such devices. The memory management for a Java program may be divided into two parts. First, the memory consumed by each object is managed by the Garbage Collection (GC), which is executed intermittently to reclaim that memory. Second, the memory consumed by the frame of a function is automatically reclaimed on the completion of function’s invocation. TakaTuka has an Offline GC to reduce the aggregated memory requirements of objects during execution of a program. The Offline GC allows freeing an object that is still reachable but is guaranteed not to be used again in the program. The Offline GC is shown to increase the amount of RAM available to a program by up to 66 % as compared with a typical online garbage collector. Another important feature of the TakaTuka JVM is variable Slot Size (VSS) scheme that reduces RAM requirements of the function’s frame. TakaTuka storage and RAM optimizations also increase the speed of a program ex- ecution thus increasing the lifetime of the mote. The storage, performance and RAM consumption features of the TakaTuka JVM makes it an attractive platform for develop- ing applications for wireless sensor networks employing microcontrollers and embedded devices. vii Acknowledgments I am very grateful to my supervisor Professor Christian Schindelhauer for his encourage- ment, help and inspiring guidance throughout the course of this work. He always believed in me and supported me in creating a team for the development of TakaTuka JVM. I could rely on him for all my problems including the personal ones. The formal and informal exchange of ideas with him and the influence of his personality helped me in becoming a better person. I am also obliged to my co-supervisor Professor Peter Thiemann for his continued guidance and counseling during this work. His qualified suggestions and vi- sion of the programming techniques proved extremely useful in corroborating my ideas and avoiding possible dead ends. I am greatly indebted to Professor Zartash Afzal Uzmi for stimulating my research interests and giving publishable shape to most of my work. I wish to thank two of my young colleagues, Luminous (Lu) Fennel and Gidon Ernst for their assistance in realizing the TakaTuka project. Gidon wrote the early version of the TakaTuka interpreter to help establish its feasibility. Lu transformed the TakaTuka JVM into a fully functional and usable form. I want to express my gratitude to Oliver Maye, of IHP-microelectronics, for certain improvements in the TakaTuka JVM and emancipating it from bugs. I would also like to acknowledge Elmar Haussmann for implementing Variable Slot Size (VSS) functionality in TakaTuka JVM, Jet Tang for porting TakaTuka to MSP430 family of processors, Omer Salem Al-Khanbushi for writing Apache-Ant script, Zhongjie Cai for improving TakaTuka multi-threads support and Shou-Yu Chao for providing Java debugger (JDB) functionality on motes and porting CLDC library to the TakaTuka JVM. I am grateful to all my friends and colleagues, especially Saqib Raza, Fahad Rafique Dogar, Arne Vater, Stefan Rührup, Wasim Malik, Asif M. Siddiqui and Professor Sohail Aslam, for continued support and encouragement I have received from them. I am hugely obligated to my parents and also to my wife and children who were always there for me and patiently waited to see me successful. My thanks are also due to my uncle Dr. I. A. Azhar who reviewed the manuscript to improve the language of the thesis. Financial support of Higher Education Commission of Pakistan for carrying out my Ph.D. program is gratefully acknowledged. ix Contents Acknowledgements ix List of Tables xiii List of Figures xv Abbreviations xvii 1 Introduction 1 1.1 Existing JVMs for Microcontrollers .................... 3 1.2 Wireless Sensor Network .......................... 3 1.3 Programming Paradigm ........................... 5 1.4 Fundamentals of a Java ........................... 6 1.5 Challenges and Contributions ........................ 10 2 Offline Garbage Collection 17 2.1 Motivating Example ............................ 19 2.2 Offline GC Data-Flow Analyzer ...................... 20 2.3 Offline Garbage Identifier .......................... 25 2.4 Runtime Implementation .......................... 33 2.5 Related Work ................................ 35 2.6 Results and Discussion ........................... 36 3 Variable Slot Size 47 3.1 VSS Instruction Design ........................... 49 3.2 Changing Bytecode for Supporting VSS .................. 52 3.3 Results and Discussion ........................... 54 xi xii Contents 4 Bytecode Compaction 57 4.1 Available Opcodes ............................. 59 4.2 Single Instruction Compaction ....................... 60 4.3 Multiple Instruction Compaction (MIC) .................. 60 4.4 Interpreter Support for Bytecode Compaction ............... 67 4.5 Results and Discussion ........................... 70 5 Class File Optimizations 83 5.1 TakaTuka Constant Pool Optimization ................... 84 5.2 Dead Code Removal ............................ 86 5.3 TUK File Format .............................. 86 5.4 Results and Discussion ........................... 89 6 Interpreter Design 91 6.1 Runtime Architecture ............................ 92 6.2 Customized JVM .............................. 92 6.3 Hardware and Operating System Abstraction Layer ............ 93 6.4 TakaTuka Linkage With TinyOS ...................... 93 6.5 Tiny Java Debugger ............................. 94 6.6 Results and Discussion ........................... 96 7 Summary and Conclusions 99 References 105 List of Tables 2.1 Benchmarks used for the evaluation of the Offline GC. .......... 39 2.2 The number of times online GC is called by the benchmark programs, with and without Offline GC. ........................ 41 3.1 Set of additional bytecode instructions in the TakaTuka VSS Extension. 51 4.2 Detailed
Load more

Recommended publications
  • Tinyos Meets Wireless Mesh Networks
    TinyOS Meets Wireless Mesh Networks Muhammad Hamad Alizai, Bernhard Kirchen, Jo´ Agila´ Bitsch Link, Hanno Wirtz, Klaus Wehrle Communication and Distributed Systems, RWTH Aachen University, Germany [email protected] Abstract 2 TinyWifi We present TinyWifi, a nesC code base extending TinyOS The goal of TinyWifi is to enable direct execution of to support Linux powered network nodes. It enables devel- TinyOS applications and protocols on Linux driven network opers to build arbitrary TinyOS applications and protocols nodes with no additional effort. To achieve this, the Tiny- and execute them directly on Linux by compiling for the Wifi platform extends the existing TinyOS core to provide new TinyWifi platform. Using TinyWifi as a TinyOS plat- the exact same hardware independent functionality as any form, we expand the applicability and means of evaluation of other platform (see Figure 1). At the same time, it exploits wireless protocols originally designed for sensornets towards the customary advantages of typical Linux driven network inherently similar Linux driven ad hoc and mesh networks. devices such as large memory, more processing power and higher communication bandwidth. In the following we de- 1 Motivation scribe the architecture of each component of our TinyWifi Implementation. Although different in their applications and resource con- straints, sensornets and Wi-Fi based multihop networks share 2.1 Timers inherent similarities: (1) They operate on the same frequency The TinyOS timing functionality is based on the hardware band, (2) experience highly dynamic and bursty links due to timers present in current microcontrollers. A sensor-node radio interferences and other physical influences resulting in platform provides multiple realtime hardware timers to spe- unreliable routing paths, (3) each node can only communi- cific TinyOS components at the HAL layer - such as alarms, cate with nodes within its radio range forming a mesh topol- counters, and virtualization.
    [Show full text]
  • Shared Sensor Networks Fundamentals, Challenges, Opportunities, Virtualization Techniques, Comparative Analysis, Novel Architecture and Taxonomy
    Journal of Sensor and Actuator Networks Review Shared Sensor Networks Fundamentals, Challenges, Opportunities, Virtualization Techniques, Comparative Analysis, Novel Architecture and Taxonomy Nahla S. Abdel Azeem 1, Ibrahim Tarrad 2, Anar Abdel Hady 3,4, M. I. Youssef 2 and Sherine M. Abd El-kader 3,* 1 Information Technology Center, Electronics Research Institute (ERI), El Tahrir st, El Dokki, Giza 12622, Egypt; [email protected] 2 Electrical Engineering Department, Al-Azhar University, Naser City, Cairo 11651, Egypt; [email protected] (I.T.); [email protected] (M.I.Y.) 3 Computers & Systems Department, Electronics Research Institute (ERI), El Tahrir st, El Dokki, Giza 12622, Egypt; [email protected] 4 Department of Computer Science & Engineering, School of Engineering and Applied Science, Washington University in St. Louis, St. Louis, MO 63130, 1045, USA; [email protected] * Correspondence: [email protected] Received: 19 March 2019; Accepted: 7 May 2019; Published: 15 May 2019 Abstract: The rabid growth of today’s technological world has led us to connecting every electronic device worldwide together, which guides us towards the Internet of Things (IoT). Gathering the produced information based on a very tiny sensing devices under the umbrella of Wireless Sensor Networks (WSNs). The nature of these networks suffers from missing sharing among them in both hardware and software, which causes redundancy and more budget to be used. Thus, the appearance of Shared Sensor Networks (SSNs) provides a real modern revolution in it. Where it targets making a real change in its nature from domain specific networks to concurrent running domain networks. That happens by merging it with the technology of virtualization that enables the sharing feature over different levels of its hardware and software to provide the optimal utilization of the deployed infrastructure with a reduced cost.
    [Show full text]
  • Low Power Or High Performance? a Tradeoff Whose Time
    Low Power or High Performance? ATradeoffWhoseTimeHasCome(andNearlyGone) JeongGil Ko1,KevinKlues2,ChristianRichter3,WanjaHofer4, Branislav Kusy3,MichaelBruenig3,ThomasSchmid5,QiangWang6, Prabal Dutta7,andAndreasTerzis1 1 Department of Computer Science, Johns Hopkins University 2 Computer Science Division, University of California, Berkeley 3 Australian Commonwealth Scientific and Research Organization (CSIRO) 4 Department of Computer Science, Friedrich–Alexander University Erlangen–Nuremberg 5 Department Computer Science, University of Utah 6 Department of Control Science and Engineering, Harbin Institute of Technology 7 Division of Computer Science and Engineering, University of Michigan, Ann Arbor Abstract. Some have argued that the dichotomy between high-performance op- eration and low resource utilization is false – an artifact that will soon succumb to Moore’s Law and careful engineering. If such claims prove to be true, then the traditional 8/16- vs. 32-bit power-performance tradeoffs become irrelevant, at least for some low-power embedded systems. We explore the veracity of this the- sis using the 32-bit ARM Cortex-M3 microprocessor and find quite substantial progress but not deliverance. The Cortex-M3, compared to 8/16-bit microcon- trollers, reduces latency and energy consumption for computationally intensive tasks as well as achieves near parity on code density. However, it still incurs a 2 overhead in power draw for “traditional” sense-store-send-sleep applica- tions.∼ × These results suggest that while 32-bit processors are not yet ready for applications with very tight power requirements, they are poised for adoption ev- erywhere else. Moore’s Law may yet prevail. 1Introduction The desire to operate unattended for long periods of time has been a driving force in de- signing wireless sensor networks (WSNs) over the past decade.
    [Show full text]
  • Building Intelligent Middleware for Large Scale CPS Systems
    Building Intelligent Middleware for Large Scale CPS Systems Niels Reijers, Yu-Chung Wang, Chi-Sheng Shih, Jane Y. Kwei-Jay Lin Hsu Department of Electrical Eng. and Comp. Sci. Intel-NTU Connected Context Computing Center University of California, Irvine National Taiwan University Irvine, CA, USA Taipei, Taiwan Abstract—This paper presents a study on building intelligent application to express globally what it really wants from the middleware on wireless sensor network (WSN) for large-scale sensor network. Furthermore, since most WSN applications are cyber-physical systems (LCPS). A large portion of WSN projects specifically designed to particular scenarios and unique target has focused on low-level algorithms such as routing, MAC layers, environments, most behavior is hardcoded, resulting in rigid and data aggregation. At a higher level, various WSN networks that are typically not very flexible at adjusting their applications with specific target environments have been behavior to faults or changing external conditions. A more high developed and deployed. Most applications are built directly on level vision on how large-scale cyber-physical systems (LCPS) top of a small OS, which is notoriously hard to work with, and or networks of sensors should be programmed, deployed, and results in applications that are fragile and cannot be ported to configured is still missing. other platforms. The gap between the low level algorithms and the application development process has received significantly Indeed, we are far from conducting Rapid Application less attention. Our interest is to fill that gap by developing Development (RAD) for LCPS. This project aims to fill the gap, intelligent middleware for building LCPS applications.
    [Show full text]
  • A Post-Apocalyptic Sun.Misc.Unsafe World
    A Post-Apocalyptic sun.misc.Unsafe World http://www.superbwallpapers.com/fantasy/post-apocalyptic-tower-bridge-london-26546/ Chris Engelbert Twitter: @noctarius2k Jatumba! 2014, 2015, 2016, … Disclaimer This talk is not going to be negative! Disclaimer But certain things are highly speculative and APIs or ideas might change by tomorrow! sun.misc.Scissors http://www.underwhelmedcomic.com/wp-content/uploads/2012/03/runningdude.jpg sun.misc.Unsafe - What you (don’t) know sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) • Used inside the JVM / JRE sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) • Used inside the JVM / JRE // Unsafe mechanics private static final sun.misc.Unsafe U; private static final long QBASE; private static final long QLOCK; private static final int ABASE; private static final int ASHIFT; static { try { U = sun.misc.Unsafe.getUnsafe(); Class<?> k = WorkQueue.class; Class<?> ak = ForkJoinTask[].class; example: QBASE = U.objectFieldOffset (k.getDeclaredField("base")); java.util.concurrent.ForkJoinPool QLOCK = U.objectFieldOffset (k.getDeclaredField("qlock")); ABASE = U.arrayBaseOffset(ak); int scale = U.arrayIndexScale(ak); if ((scale & (scale - 1)) != 0) throw new Error("data type scale not a power of two"); ASHIFT = 31 - Integer.numberOfLeadingZeros(scale); } catch (Exception e) { throw new Error(e); } } } sun.misc.Unsafe
    [Show full text]
  • A Comparative Study Between Operating Systems (Os) for the Internet of Things (Iot)
    VOLUME 5 NO 4, 2017 A Comparative Study Between Operating Systems (Os) for the Internet of Things (IoT) Aberbach Hicham, Adil Jeghal, Abdelouahed Sabrim, Hamid Tairi LIIAN, Department of Mathematic & Computer Sciences, Sciences School, Sidi Mohammed Ben Abdellah University, [email protected], [email protected], [email protected], [email protected] ABSTRACT Abstract : We describe The Internet of Things (IoT) as a network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data in real time with the outside world. It therefore assumes an operating system (OS) which is considered as an unavoidable point for good communication between all devices “objects”. For this purpose, this paper presents a comparative study between the popular known operating systems for internet of things . In a first step we will define in detail the advantages and disadvantages of each one , then another part of Interpretation is developed, in order to analyze the specific requirements that an OS should satisfy to be used and determine the most appropriate .This work will solve the problem of choice of operating system suitable for the Internet of things in order to incorporate it within our research team. Keywords: Internet of things , network, physical object ,sensors,operating system. 1 Introduction The Internet of Things (IoT) is the vision of interconnecting objects, users and entities “objects”. Much, if not most, of the billions of intelligent devices on the Internet will be embedded systems equipped with an Operating Systems (OS) which is a system programs that manage computer resources whether tangible resources (like memory, storage, network, input/output etc.) or intangible resources (like running other computer programs as processes, providing logical ports for different network connections etc.), So it is the most important program that runs on a computer[1].
    [Show full text]
  • Arxiv:1712.05590V2 [Cs.PL] 18 Dec 2017 Ffaue,Btsffrfo Lwono N Otoodr Fm and of Throughput Orders Reducing Two to Consumption
    Abstract Many virtual machines exist for sensor nodes with only a few KB RAM and tens to a few hundred KB flash memory. They pack an impressive set of features, but suffer from a slowdown of one to two orders of magnitude compared to optimised native code, reducing throughput and increasing power consumption. Compiling bytecode to native code to improve performance has been studied extensively for larger devices, but the restricted resources on sen- sor nodes mean most modern techniques cannot be applied. Simply replac- ing bytecode instructions with predefined sequences of native instructions is known to improve performance, but produces code several times larger than the optimised C equivalent, limiting the size of programmes that can fit onto a device. This paper identifies the major sources of overhead resulting from this basic approach, and presents optimisations to remove most of the remain- ing performance overhead, and over half the size overhead, reducing them to 69% and 91% respectively. While this increases the size of the VM, the break-even point at which this fixed cost is compensated for is well within the range of memory available on a sensor device, allowing us to both improve performance and load more code on a device. arXiv:1712.05590v2 [cs.PL] 18 Dec 2017 1 Improved Ahead-of-Time Compilation of Stack-Based JVM Bytecode on Resource-Constrained Devices Niels Reijers, Chi-Sheng Shih NTU-IoX Research Center Department of Computer Science and Information Engineering National Taiwan University 1 Introduction Internet-of-Things devices come in a wide range, with vastly different perfor- mance characteristics, cost, and power requirements.
    [Show full text]
  • RIOT: One OS to Rule Them All in the Iot Emmanuel Baccelli, Oliver Hahm
    RIOT: One OS to Rule Them All in the IoT Emmanuel Baccelli, Oliver Hahm To cite this version: Emmanuel Baccelli, Oliver Hahm. RIOT: One OS to Rule Them All in the IoT. [Research Report] RR-8176, 2012. hal-00768685v1 HAL Id: hal-00768685 https://hal.inria.fr/hal-00768685v1 Submitted on 3 Jan 2013 (v1), last revised 16 Jan 2013 (v3) 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. RIOT: One OS to Rule Them All in the IoT E. Baccelli, O. Hahm RESEARCH REPORT N° 8176 December 2012 Project-Team HiPERCOM ISSN 0249-6399 ISRN INRIA/RR--8176--FR+ENG RIOT: One OS to Rule Them All in the IoT E. Baccelli, O. Hahm ∗ Project-Team HiPERCOM Research Report n° 8176 — December 2012 — 10 pages Abstract: The Internet of Things (IoT) embodies a wide spectrum of machines ranging from sensors powered by 8-bits microcontrollers, to devices powered by processors roughly equivalent to those found in entry-level smartphones. Neither traditional operating systems (OS) currently running on internet hosts, nor typical OS for sensor networks are capable to fulfill all at once the diverse requirements of such a wide range of devices.
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • 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.
    [Show full text]
  • The Use of Java in the Context of AUTOSAR 4.0
    The Use of Java in the Context of AUTOSAR 4.0 Expectations and Possibilities Christian Wawersich [email protected] MethodPark Software AG, Germany Isabella Thomm Michael Stilkerich {ithomm,stilkerich}@cs.fau.de Friedrich-Alexander University Erlangen-Nuremberg, Germany ABSTRACT architecture for system functionality and drivers in automo- Modern cars contain a large number of diverse microcon- tive software. It is motivated by the growing complexity of trollers for a wide range of tasks, which imposes high efforts software functionality provided in cars and facilitates the in the integration process of hardware and software. There integration of multiple applications on fewer, more powerful is a paradigm shift from a federated architecture to an inte- microcontrollers. grated architecture with commonly used resources to reduce Standardized, tested software modules as specified by AU- complexity, costs, weight and energy. TOSAR are shown to contain less software bugs. However, AUTOSAR [3] is a system platform that allows the inte- only a part of a complete AUTOSAR compliant software sys- gration of software components (SW-C) and basic software tem is covered by the standard. Applications, ECU specific modules provided by different manufacturers. The system functionality and drivers for microcontroller external devices platform can be tailored in a wide range to efficiently use have to be developed independently for each project. the resources of the individual electronic control unit. In a network of dedicated microcontrollers, the deployed Software modules - mostly written in C or even Assembler software is physically isolated from each other. This isolation - are rarely isolated from each other and have global access is missing among applications running on the same microcon- to the memory, wherefore an error can easily spread among troller, which enables malfunctioning applications to corrupt different software modules.
    [Show full text]
  • By Syed Ishtiaq Hussain Supervised by Dr. Humma Javed
    RESOURCE AWARE PROCESS MIGRATION IN WIRELESS SENSOR NETWORKS By Syed Ishtiaq Hussain Supervised By Dr. Humma Javed DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF PESHAWAR SESSION 2009-2010 RESOURCE AWARE PROCESS MIGRATION IN WIRELESS SENSOR NETWORKS By Syed Ishtiaq Hussain Dissertation Submitted to the University of Peshawar in partial fulfillment of the requirement for the degree of DOCTOR OF PHILOSOPHY Supervised By Dr. Humma Javed DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF PESHAWAR SESSION 2009-2010 DEDICATION Dedicated to my beloved parents, and my kids… iv STATEMENT OF SOURCES DECLARATION I, the undersigned, author of this thesis, declare that this thesis is my own work and has not been submitted in any form for another degree at any university or institution. Information derived from published or unpublished work of others has been acknowledged in the text and a list of references is given. __________________ ______________ Syed Ishtiaq Hussain 28th September 2018 v RIGHTS OF THESIS All parts of this dissertation are reserved by the author, any part of this research shall not be produced or transmitted in any form or by any means, without formal permission from the author. Syed Ishtiaq Hussain vi ABSTRACT This thesis presents a novel architecture for native process migration (PM) in wireless sensors networks (WSN) without the use of virtual execution environment. Resources in WSN are scarce, therefore creating a virtual execution environment for processes so that they can be migrated, put an extra burden on already constrained resources. The proposed architecture for process migration allows live native processes to be migrated during execution. The process migration architecture takes migration decisions by continuously monitoring resources including remaining battery life and free memory space on a node.
    [Show full text]