Detecting anomalous energy consumption in android applications

The use of powerful mobile devices, like smartphones, tablets and laptops, are changing the way programmers develop software. While in the past the primary goal to optimize software was the run time optimization, nowadays there is a growing awareness of the need to reduce energy consumption. This paper presents a technique and a tool to detect anomalous energy consumption in Android applications, and to relate it directly with the source code of the application. We propose a dynamically calibrated model for energy consumption for the Android ecosystem, and that supports different devices. The model is then used as an API to monitor the application execution: first, we instrument the application source code so that we can relate energy consumption to the application source code; second, we use a statistical approach, based on fault-localization techniques, to localize abnormal energy consumption in the source code

Java Dust: How Small Can Embedded Java Be?

Java is slowly being accepted as a language and platform for embedded devices. However, the memory requirements of the Java library and runtime are still troublesome. A Java system is considered small when it requires less than 1 MB, and within the embedded domain small microcontollers with a few KB on-chip Flash memory and even less on-chip RAM are very common. For such small devices Java is a clearly challenging. In this paper we present the combination of the Java compiler Muvium for microcontrollers with the tiny soft-core Leros for an FPGA. To the best of our knowledge, the presented embedded Java system is the smallest Java system available. The Leros processor consumes less than 5 % of the logic cells of the smallest FPGA from Altera and the Muvium compiler produces a JVM, including the Java application, that can execute in a few KB ROM and less than 1 KB RAM. The Leros processor is available in open-source and the Leros port of Muvium is freely available

VXA: A Virtual Architecture for Durable Compressed Archives

Data compression algorithms change frequently, and obsolete decoders do not always run on new hardware and operating systems, threatening the long-term usability of content archived using those algorithms. Re-encoding content into new formats is cumbersome, and highly undesirable when lossy compression is involved. Processor architectures, in contrast, have remained comparatively stable over recent decades. VXA, an archival storage system designed around this observation, archives executable decoders along with the encoded content it stores. VXA decoders run in a specialized virtual machine that implements an OS-independent execution environment based on the standard x86 architecture. The VXA virtual machine strictly limits access to host system services, making decoders safe to run even if an archive contains malicious code. VXA's adoption of a "native" processor architecture instead of type-safe language technology allows reuse of existing "hand-optimized" decoders in C and assembly language, and permits decoders access to performance-enhancing architecture features such as vector processing instructions. The performance cost of VXA's virtualization is typically less than 15% compared with the same decoders running natively. The storage cost of archived decoders, typically 30-130KB each, can be amortized across many archived files sharing the same compression method.Comment: 14 pages, 7 figures, 2 table

Data utilization software for assisting power plant project sales

A business opportunity in power plant project sales goes through several stages before a quote can be made. Previously made quotes can offer insight on how earlier projects were sold in certain areas or countries. Therefore, a salesperson working in energy business will often want to compare the cost and scope of current power plant projects with earlier sold projects. The role of web applications continues to grow. Increasing amount of software developers write their software for web browsers. In addition, modern software development tools such as Django and React allow efficient web development. Since the popularity of web applications is increasing, web browsers have become the main platform for new applications. In this thesis, a prototype web application is designed and developed. The application allows a salesperson to compare current power plant projects with previously sold projects. The comparison process should mainly illustrate how the costs of the compared projects differ from one another. The goal of the application is to enable sales personnel to access relevant data and make comparisons by utilizing just a single application instead of using many separate systems. This reduces the workload in sales department and increases the productivity in power plant project sales. The prototype application developed in this thesis will be integrated into energy feasibility tools platform, which hosts several different applications used in energy sales. Furthermore, the application should utilize data located on Wärtsilä Data Platform. The prototype is written with Python and JavaScript programming languages. The backend server is created by utilizing Django web framework. The user interface of the application is constructed with React and Semantic UI libraries. The users of the application are authenticated with the help of OAuth 2.0 authorization framework. In this thesis, a working prototype application was designed and developed. The resulting application allows a salesperson to compare different power plant projects and examine the details of individual projects. The application developed in the thesis can be used in the future as a model for similar systems utilizing Wärtsilä Data Platform data. Currently, the application is mainly designed for engine power plant data. However, in the future the application could be modified to work better with energy storage data. Finally, it should be investigated whether machine learning algorithms could be used to offer recommendations for users based on the data of previous projects.Voimalaitosprojektin myyntiprosessi koostuu useista vaiheista, joiden aikana liiketoimintamahdollisuudesta kehittyy tarjous. Aiemmin tehdyt tarjoukset voivat tarjota tietoa siitä, kuinka edellisiä projekteja on myyty tietyissä maanosissa tai valtioissa. Tästä syystä myyntihenkilöt haluavat usein vertailla meneillään olevien projektien kustannuksia ja laajuutta aiemmin myytyihin projekteihin. Web-sovellusten rooli on kasvanut vuosien varrella. Kasvava joukko sovelluskehittäjiä kirjoittaakin nykyään sovelluksiaan web-selaimille. Tämän lisäksi modernit kehitystyökalut kuten Django ja React lisäävät sovelluskehityksen tehokkuutta. Web-sovellusten kasvava rooli onkin tehnyt web-selaimista tärkeimmäin alustan uusille sovelluksille. Tämän diplomityön tarkoituksena on suunnitella sekä kehittää prototyyppi web-sovellus. Tämä sovellus auttaa myyjiä vertailemaan meneillä olevia voimalaitosprojekteja aiemmin myytyihin projekteihin. Vertailuprosessin päämäärä on lähinnä havainnollistaa, kuinka eri projektien kustannukset eroavat toisistaan. Työn tavoite on auttaa myyjiä hyödyntämään ja vertailemaan voimalaitosprojektien dataa käyttämällä pelkästään yhtä sovellusta. Mikäli voimalaitosdataa voitaisiin vertailla yhdellä sovelluksella useiden hajanaisten sovelluskokonaisuuksien käyttämisen sijaan, myyjien työtaakka vähentyisi ja samalla tuottavuus voimalaitosprojektien myynnissä kasvaisi. Tässä diplomityössä kehitetty prototyyppisovellus liitetään osaksi energy feasibility tools työkalua, joka toimii alustana useille eri voimalaitossovelluksille. Tämän lisäksi työssä kehitetty sovellus hyödyntää Wärtsilä Data Platform yritystietovarastossa olevaa dataa. Työssä toteutettava protyyppisovellus ohjelmoidaan Python ja JavaScript ohjelmointikieliä käyttäen. Palvelimen toiminnallisuudet luodaan käyttämällä Django web-sovelluskehystä. Sovelluksen käyttöliittymä rakennetaan hyödyntämällä React ja Semantic UI kirjastoja. Protyyppisovelluksen käyttäjät tullaan todentamaan käyttämällä OAuth 2.0 kehystä. Tässä diplomityössä suunniteltiin ja kehitettiin toimiva prototyyppisovellus. Tätä sovellusta käyttävät myyjät pystyvät vertailemaan erilaisia voimalaitosprojekteja sekä tarkastelemaan yksittäisten voimalaitosprojektien yksityiskohtia. Työssä kehitetty sovellus voisi toimia tulevaisuudessa mallina vastaavan kaltaisille Wärtsilä Data Platform dataa hyödyntäville sovelluksille. Tällä hetkellä sovellus on suunniteltu lähinnä moottorivoimalaitosprojekteja varten. Tulevaisuudessa sovellusta voitaisiin räätälöidä siten, että se sopisi paremmin myös energian varastointia koskeviin projekteihin. Varteenotettavaa olisi myös tutkia, pystyisikö koneoppimismenetelmillä tarjota käyttäjille dataan perustuvia suosituksia

가상머신의 메모리 관리 최적화

학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 2014. 2. 문수묵.Memory management is one of key components in virtual machine and also affects overall performance of virtual machine itself. Modern programming languages for virtual machine use dynamic memory allocation and objects are allocated dynamically to heap at a higher rate, such as Java. These allocated objects are reclaimed later when objects are not used anymore to secure free room in the heap for future objects allocation. Many virtual machines adopt garbage collection technique to reclaim dead objects in the heap. The heap can be also expanded itself to allocate more objects instead. Therefore overall performance of memory management is determined by object allocation technique, garbage collection and heap management technique. In this paper, three optimizing techniques are proposed to improve overall performance of memory management in virtual machine. First, a lazy-worst-fit object allocator is suggested to allocate small objects with little overhead in virtual machine which has a garbage collector. Then a biased allocator is proposed to improve the performance of garbage collector itself by reducing extra overhead of garbage collector. Finally an ahead-of-time heap expansion technique is suggested to improve user responsiveness as well as overall performance of memory management by suppressing invocation of garbage collection. Proposed optimizations are evaluated in various devices including desktop, embedded and mobile, with different virtual machines including Java virtual machine for Java runtime and Dalvik virtual machine for Android platform. A lazy-worst-fit allocator outperform other allocators including first-fit and lazy-worst-fit allocator and shows good fragmentation as low as rst-t allocator which is known to have the lowest fragmentation. A biased allocator reduces 4.1% of pause time caused by garbage collections in average. Ahead-of-time heap expansion reduces both number of garbage collections and total pause time of garbage collections. Pause time of GC reduced up to 31% in default applications of Android platform.Abstract i Contents iii List of Figures vi List of Tables viii Chapter 1 Introduction 1 1.1 The need of optimizing memory management . . . . . . . . . . . 2 1.2 Outline of the Dissertation . . . . . . . . . . . . . . . . . . . . . . 3 Chapter 2 Backgrounds 4 2.1 Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Memory management in virtual machine . . . . . . . . . . . . . . 5 Chapter 3 Lazy Worst Fit Allocator 7 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Allocation with fits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Lazy fits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 Lazy worst fit . . . . . . . . . . . . . . . . . . . . . . . . . 13 iii 3.4 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 LWF implementation in the LaTTe Java virtual machine 14 3.4.2 Experimental environment . . . . . . . . . . . . . . . . . . 16 3.4.3 Performance of LWF . . . . . . . . . . . . . . . . . . . . . 17 3.4.4 Fragmentation of LWF . . . . . . . . . . . . . . . . . . . . 20 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Chapter 4 Biased Allocator 24 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3 Biased allocator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1 When to choose an allocator . . . . . . . . . . . . . . . . 28 4.3.2 How to choose an allocator . . . . . . . . . . . . . . . . . 30 4.4 Analyses and implementation . . . . . . . . . . . . . . . . . . . . 32 4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.5.1 Total pause time of garbage collections . . . . . . . . . . . 36 4.5.2 Eect of each analysis . . . . . . . . . . . . . . . . . . . . 38 4.5.3 Pause time of each garbage collection . . . . . . . . . . . 38 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Chapter 5 Ahead-of-time Heap Management 42 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.1 Garbage Collection . . . . . . . . . . . . . . . . . . . . . . 48 5.3.2 Heap expansion heuristic . . . . . . . . . . . . . . . . . . 49 5.4 Ahead-of-time heap expansion . . . . . . . . . . . . . . . . . . . . 51 5.4.1 Spatial heap expansion . . . . . . . . . . . . . . . . . . . . 53 iv 5.4.2 Temporal heap expansion . . . . . . . . . . . . . . . . . . 55 5.4.3 Launch-time heap expansion . . . . . . . . . . . . . . . . 56 5.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5.1 Spatial heap expansion . . . . . . . . . . . . . . . . . . . . 58 5.5.2 Comparision of spatial heap expansion . . . . . . . . . . . 61 5.5.3 Temporal heap expansion . . . . . . . . . . . . . . . . . . 70 5.5.4 Launch-time heap expansion . . . . . . . . . . . . . . . . 72 5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Chapter 6 Conculsion 74 Bibliography 75 요약 84 Acknowledgements 86Docto

어플리케이션 다운로딩 시스템을 위한 클라이언트 선행 컴파일러

학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 2014. 8. 문수묵.어플리케이션(앱)을 다운로드 받아서 수행하는 시스템은 DTV나 스마트폰처럼 대중적으로 사용되고 있다. 앱을 다운받아서 사용하는 시스템들은 가상 머신을 주류로 사용하고 있다. 가상 머신의 가장 큰 문제점은 인터프리터를 통한 수행에 의한 느린 성능이며, 이 성능의 향상을 위해 주로 사용되는 기술이 적시 컴파일러이다. 적시 컴파일러는 다운받은 앱의 수행 중에 동적으로 머신 코드로 번역하여 사용하는 기법으로, 동적 컴파일레이션 오버헤드를 가지게 된다. 우리는 이 동적 컴파일레이션 오버헤드를 제거하여 성능을 향상시키는 클라이언트 선행 컴파일러를 제안하였다. 클라이언트 선행 컴파일러는 적시 컴파일러가 생성하는 머신 코드를 앱의 종료될 때 지우지 않고 파일형태로 스토리지에 저장하여 이후에 앱이 다시 수행될 때 저장한 머신 코드를 재활용하여 사용함으로써 런타임 컴파일레이션 오버헤드를 제거하게 된다. 저장한 머신 코드를 재활용할 때 머신 코드에 인코딩된 주소값들은 유효하지 않기 때문에 가상 머신의 현재 값에 맞추어 변경해주는 작업이 필요하다. 이 작업은 주소 재배치이다. 주소 재배치는 저장된 머신 코드만으로 수행할 수가 없기 때문에 추가적인 정보를 머신 코드를 저장하는 과정에서 생성하여 파일에 함께 저장해 주어야 한다. 자바의 상수 풀 해석은 주소 재배치 작업을 어렵게 한다. 우리는 이에 대한 해결책을 만들었다. 주소 재배치를 위한 정보들을 저장하기위해 영구 메모를 많이 사용하는 것도 문제가 된다. 따라서 우리는 주소 재배치 정보를 머신 코드 상에 인코딩하고 압축하여 저장하는 방법을 제안했다. 우리의 클라이언트 선행 컴파일러 기법은 오라클사의 CDC 가상머신 참조구현인 CVM에 구현하였다. 우리의 클라이언트 선행 컴파일러는 벤치마크의 성능을 약 12% 향상시켰다. 또한 우리는 클라이언트 선행 컴파일러 기법을 실제로 판매하는 DTV환경에 구축하여 실제 방송국이 사용하는 어플리케이션을 수행해 보았다. 우리의 클라이언트 선행 컴파일러 방식은 사용자의 실제 환경에서 33%의 좋은 성능 향상을 얻었다. 자바스크립트 가상머신인 구글사의 V8 가상머신은 인터프리터 수행없이 적시 컴파일러만을 사용하고 있다. 우리는 V8 가상 머신에 클라이언트 선행 컴파일러는 적용하였지만, 실제 성능 향상을 얻어내지는 못했다. 이것은 V8 가상 머신의 특징인 내부 객체의 적극적인 사용에 의한 결과이다. 내부 객체는 컴파일러가 생성하여 컴파일러 과정에서 사용되며, 자바스크립트 프로그램에서도 접근하여 사용하게 된다. V8 가상 머신의 컴포넌트들은 대부분 내부 객체로 생성되어, 다른 종류의 가상 머신에 비해서 상당히 많은 내부 객체를 생성하고 있다. V8의 적시 컴파일러가 생성하는 머신 코드에서는 이 내부 객체를 직접 접근하여 사용하게 되어, 클라이언트 선행 컴파일러에 의해 어플리케이션이 수행될 때마다 이 내부 객체는 항상 필요하기 때문에 클라이언트 선행 컴파일러는 내부 객체를 재생성해야만 한다. V8 적시 컴파일러의 런타임 컴파일레이션 오버헤드의 대부분이 내부 객체를 생성하는 오버헤드이기 때문에, 우리의 클라이언트 선행 컴파일러는 이 환경에서 충분한 성능 향상을 얻을 수 없었다.App-downloading systems like DTV and smart phone are popularly used. Virtual machine is mainstream for those systems. One critical problem of app-downloading systems is performance because app is executed by interpreter. A popular solution for improving performance is Just-In-Time Compiler (JITC). JITC compiles to machine code at runtime. So, JITC suffers from runtime compilation overhead. We suggested client Ahead-Of-Time Compiler(c-AOTC) which improves the performance by removing runtime compilation overhead. c-AOTC saves machine code of method generated by JITC in persistent storage and reuses it in next runs. The machine code of a method translated by JITC is cached on a persistent memory of the device, and when the method is invoked again in a later run of the program, the machine code is loaded and executed directly without any translation overhead. One major issue in c-AOTC is relocation because some of the address constants embedded in the cached machine code are not correct when the machine code is loaded and used in a different runthose addresses should be corrected before they are used. Constant pool resolution complicates the relocation problem, and we propose our solutions. The persistent memory overhead for saving the relocation information is also an issue, and we propose a technique to encode the relocation information and compress the machine code efficiently. We developed a c-AOTC on Oracles CDC VM, and evaluation results indicate that c-AOTC can improve the performance as much as an average of 12% for benchmarks. And we adopted c-AOTC approach to commercial DTV platform and test the real xlet applications of commercial broadcasting stations. c-AOTC got average 33% performance improvement on the real xlet application test. V8 JavaScript VM does not use interpreter. Apps are executed only by JITC. We adopted c-AOTC to V8 VM. But we cannot get any good performance result because of V8 VMs characteristics. V8 VM components are generated as internal objects. Internal objects are used for compiling and running of JavaScript program. The machine code of V8 VM addresses internal objects which are different for each run. Because internal objects be　accessed in each run, c-AOTC　must recreate those objects. Because most of compilation overhead of V8 VM is internal object creation overhead, c-AOTC　does not get enough improvements.Chapter 1 Introduction 1 Chatper 2 client-AOTC Approach 4 Chatper 3 Java Virtual Machine and Our JITC 9 3.1 Overview of JVM and the Bytecode 9 3.2 Our JITC on the CVM 14 Chatper 4 Design and Implementation of c-AOTC on JVM 16 4.1 Architecutre of the c-AOTC 16 4.2 Relocation 19 4.2.1 Translated Code Which Needs Relocation 19 4.2.2 Relocation Information and Relocation Process 22 4.2.3 Relocation for Inlined Methods 24 4.3 Reducing the Size of .aotc Files 25 4.3.1 Encoding Relocation Information 25 4.3.2 Machine Code Compression 27 4.3.3 Structure of the .aotc File 27 Chatper 5 c-AOTC for DTV JVM platform 29 5.1 DTV software platform 30 5.2 c-AOTC on the DTV 32 5.2.1 Design of c-AOTC on DTV 32 5.2.2 Relocation Problem 35 5.2.3 Example of Relocation 39 5.2.3.1 Relocation Example of JVM c-AOTC 39 5.2.3.3 Relocation Example of DTV c-AOTC 41 Chatper 6 c-AOTC for JavaScript VM 44 6.1 V8 JavaScript VM 44 6.2 Issue and Solution of c-AOTC on V8 JavaScript VM 46 Chatper 7 Experimental Results 51 7.1 Experimental Environment of JVM 51 7.2 Performance Impact of c-AOTC 53 7.3 Space Overhead of c-AOTC 55 7.4 Reducing Number of c-AOTC Methods 60 7.5 c-AOTC with new hot-spot detection heuristics 63 7.5.1 Performance Impact of c-AOTC with new hot-spotdetection heuristics 63 7.5.2 Space Overhead of c-AOTC with new hot-spot detection heuristics 67 7.6 c-AOTC of DTV JVM platform 70 7.6.1 Performance result of DTV platform 70 7.6.2 Analysis of JITCed method of DTV platform 72 7.6.3 Space overhead of DTV platform 74 7.6.4 c-AOTC overhead of DTV platform 75 7.6.5 c-AOTC performance using different xlets c-AOTC file in DTV platform 76 7.7 c-AOTC of V8 JavaScript engine 79 7.7.1 Compilation overhead on V8 JavaScript VM 79 7.7.2 Performance result on V8 JavaScript VM 81 7.7.3 Comparison with c-AOTC of JavaScriptCore VM 83 Chatper 8 Related Work 86 Chatper 9 Conclusion 89 Bibliography 91 초록 99Docto

The design and implementation of a C compiler for SAFA

Master'sMASTER OF SCIENC

Compilation statique de Java

Mémoire numérisé par la Direction des bibliothèques de l'Université de Montréal