A Compiler and Runtime Infrastructure for Automatic Program Distribution

This paper presents the design and the implementation of a compiler and runtime infrastructure for automatic program distribution. We are building a research infrastructure that enables experimentation with various program partitioning and mapping strategies and the study of automatic distribution's effect on resource consumption (e.g., CPU, memory, communication). Since many optimization techniques are faced with conflicting optimization targets (e.g., memory and communication), we believe that it is important to be able to study their interaction. We present a set of techniques that enable flexible resource modeling and program distribution. These are: dependence analysis, weighted graph partitioning, code and communication generation, and profiling. We have developed these ideas in the context of the Java language. We present in detail the design and implementation of each of the techniques as part of our compiler and runtime infrastructure. Then, we evaluate our design and present preliminary experimental data for each component, as well as for the entire system

Using High-Rising Cities to Visualize Performance in Real-Time

For developers concerned with a performance drop or improvement in their software, a profiler allows a developer to quickly search and identify bottlenecks and leaks that consume much execution time. Non real-time profilers analyze the history of already executed stack traces, while a real-time profiler outputs the results concurrently with the execution of software, so users can know the results instantaneously. However, a real-time profiler risks providing overly large and complex outputs, which is difficult for developers to quickly analyze. In this paper, we visualize the performance data from a real-time profiler. We visualize program execution as a three-dimensional (3D) city, representing the structure of the program as artifacts in a city (i.e., classes and packages expressed as buildings and districts) and their program executions expressed as the fluctuating height of artifacts. Through two case studies and using a prototype of our proposed visualization, we demonstrate how our visualization can easily identify performance issues such as a memory leak and compare performance changes between versions of a program. A demonstration of the interactive features of our prototype is available at https://youtu.be/eleVo19Hp4k.Comment: 10 pages, VISSOFT 2017, Artifact: https://github.com/sefield/high-rising-city-artifac

Scaling Virtualized Smartphone Images in the Cloud

Üks selle Bakalaureuse töö eesmärkidest oli Android-x86 nutitelefoni platvormi juurutamine pilvekeskkonda ja välja selgitamine, kas valitud instance on piisav virtualiseeritud nutitelefoni platvormi juurutamiseks ning kui palju koormust see talub. Töös kasutati Amazoni instance'i M1 Small, mis oli piisav, et juurutada Androidi virtualiseeritud platvormi, kuid jäi kesisemaks kui mobiiltelefon, millel teste läbi viidi. M1 Medium instance'i tüüp oli sobivam ja näitas paremaid tulemusi võrreldes telefoniga. Teostati koormusteste selleks vastava tööriistaga Tsung, et näha, kui palju üheaegseid kasutajaid instance talub. Testi läbiviimiseks paigaldasime Dalviku instance'ile Tomcat serveri. Pärast teste ühe eksemplariga, juurutasime külge Elastic Load Balancing ja automaatse skaleerimise Amazon Auto Scaling tööriista. Esimene neist jaotas koormust instance'ide vahel. Automaatse skaleerimise tööriista kasutasime, et rakendada horisontaalset skaleerimist meie Android-x86 instance'le. Kui CPU tõusis üle 60% kauemaks kui üks minut, siis tehti eelmisele identne instance ja koormust saadeti edaspidi sinna. Seda protseduuri vajadusel korrati maksimum kümne instance'ini. Meie teostusel olid tagasilöögid, sest Elastic Load Balancer aegus 60 sekundi pärast ning me ei saanud kõikide välja saadetud päringutele vastuseid. Serverisse saadetud faili kirjutamine ja kompileerimine olid kulukad tegevused ja seega ei lõppenud kõik 60 sekundi jooksul. Me ei saanud koos Load Balancer'iga läbiviidud testidest piisavalt andmeid, et teha järeldusi, kas virtualiseeritud nutitelefoni platvorm Android on hästi või halvasti skaleeruv.In this thesis we deployed a smartphone image in an Amazon EC2 instance and ran stress tests on them to know how much users can one instance bear and how scalable it is. We tested how much time would a method run in a physical Android device and in a cloud instance. We deployed CyanogenMod and Dalvik for a single instance. We used Tsung for stress testing. For those tests we also made a Tomcat server on Dalvik instance that would take the incoming file, the file would be compiled with java and its class file would be wrapped into dex, a Dalvik executable file, that is later executed with Dalvik. Three instances made a Tsung cluster that sent load to a Dalvik Virtual Machine instance. For scaling we used Amazon Auto Scaling tool and Elastic Load Balancer that divided incoming load between the instances

A trustworthy mobile agent infrastructure for network management

Despite several advantages inherent in mobile-agent-based approaches to network management as compared to traditional SNMP-based approaches, industry is reluctant to adopt the mobile agent paradigm as a replacement for the existing manager-agent model; the management community requires an evolutionary, rather than a revolutionary, use of mobile agents. Furthermore, security for distributed management is a major concern; agent-based management systems inherit the security risks of mobile agents. We have developed a Java-based mobile agent infrastructure for network management that enables the safe integration of mobile agents with the SNMP protocol. The security of the system has been evaluated under agent to agent-platform and agent to agent attacks and has proved trustworthy in the performance of network management tasks

Comparison of allocation trackers in JVM

Mälueraldamiste jälgija (Memory allocation tracker) on tööriist, mis registreerib objektide loomisi JVM’is. Tavaliselt, mälueraldamiste jälgija on profileerija alamosa. Sams eksisteerivad ka eraldiseisvad lahendused. Töö põhieesmärk on läbi vaadata ja võrrelda olemasolevate avatud lähtekoodiga mälueraldamiste jälgijaid. Selleks, et mõõta mälueraldamiste jälgijate effektivsus kasutasime SPECjvm2008 jõudlustestide komplekt. Mälu kasutamise mõõtmiseks oli kirjatud oma JVM TI agent, mis perioodiliselt kirjutab kasutatud mälu suurus CSV faili. Töö käigus olid läbi vaadatud ja testitud selliseid mälueraldamiste jälgimise lahendusi: • HRPOF – lihtne käsurea kasutajaliidesega profileerimise tööriist, mis pakutakse JavaDevelopment Kit (JDK) koosseisus. • NetBeans profileerija – varem see oli eraldiseisav avatud lähtekoodiga uurimis proekt nimega JFluid. Praegu see on NetBeansi osa. • TPTP profileerija – profileerija, mis kasutatakse Eclipse IDE’s. • Project Allocation Instrumenter – mälu eraldamiste jälgija Google’st. On kirjutatud puhtas Javas. Kasutab java.lang.instrument API ja ASM raamistikku baitkoodi analüüsimiseks ja manipuleerimiseks. Neljast kahel mäluereldamiste jälgijatel olid probleemid stabiilsusega. NetBeans valesti muutus javazoom.jl.decoder.huffcodetab klassi baitkoodi, mille pärast ei saanud mpegaudio testi käivitada. Eclipse TPTP profileerija ei suutnud edukalt oma tööd lõpetada mitmel korral erinevate jõudlustestide käivitamise ajal. NetBeans profileerija on tehniliselt kõige arenenum ja kõike tõhusam mäluerdlamiste jälgimise lahendus. See ei ole üllatav, kuna Sun’i insenerid kirjutasid seda parrallelselt Java virtualse masina arenguga. Kõige problemaatilisem mälueraldamiste jälgimise mõttes oli sunflow jõudlustest. Koos TPTP profileerijaga ta jooksis umbes 300 korda aeglasemalt. HPROF’i ja Allocation Instrumenter’i tulemused ei olnud määrkimväärselt paremad. Ainult NetBeans profileerija said enam-vähem efektiivselt töötada sellel testil. Kõik läbi vaadatud lahendused, välja arvatud TPTP, kasutavad mälueraldamiste jälgmiseks baitkoodi manipuleerimist (ByteCode Instrumentation, BCI). Nad lisavad oma jälgimise meetodi väljakutse pärast iga objekti loomise baitkoodi (opcode new). TPTP oma tööks kasutab JVM TI sündmuseid. Erilist huvi pakkub Allocation Instrumenter Google’st. See raamistik võimaldab kirjutada mälueraldamiste jälgijat puhtas Java keeles. Potensiaalselt see teeb lahendus platvorimst sõltumatuks. Kuid veel eksisteerivad lahendamata probleeme jõudlusega. Minu tulevikuplaanis on aru saada, kas saab teha mälueraldamiste jälgimist.Memory leaks in Java are not the same as memory leaks in, for example, the C programming language. When a C-programmer wants to use memory on the heap, he should manually allocate a memory region. After application finishes using this memory, it should be manually freed. If the pointer to the allocated region is lost, then there is no appropriate way to release this memory. This situation is called a “memory leak”. In Java the Java Virtual Machine (JVM) handles all work with memory. When a developer wants to create and use a new object, the JVM allocates a necessary amount of memory. During an application’s life the JVM periodically checks for objects in memory that are not used anymore. Objects, which are not referenced, will be discarded and memory reclaimed to be used again. This process is called garbage collection. A memory leak in Java is a situation, where an application is not logically using objects, to which references still exist, meaning the Garbage Collector (GC) can’t mark them as unused and free memory. When memory management of JVM cannot allocate any more memory, java.lang.OutOfMemoryError exception is thrown. When a developer is faced with an “OutOfMemoryError” on production server, he can try to reproduce the problem in a test environment. Unfortunately, oftentimes test environments do not allow for reproduction of such errors. It’s not always possible to mimic all parameters of a real environment. Developer often doesn’t have all required input data or he just does not know how and why the memory leak occurred. This can be also caused by all sorts of bureaucratic obstacles and barriers in large companies with separate operations and development departments and developers just do not have full access to machines in a real environment. However, even if it is possible to search for memory leaks in a production environment – use of many developer’s tools, such as full-featured profilers is not possible, due to the memory and performance overhead not suitable for production environment. It is useful to apply all possible offline methods, such as analysis of heap dumps and collection of allocations’ logs. And when a memory leak is localized, only then it would be helpful to turn on an allocation tracker for a specific set of objects or allocation sites to find out what code is responsible for creating objects that are eventually leaked. In order to do it in a production environment, we need effective methods and algorithms for allocation tracking. Memory allocations tracker is a tool, which works in runtime and logs memory allocation by specific objects or sites. Usually it is a part of a profiler, but standalone solutions also exist. The aim of this work is to review and compare existing open source solutions for allocation tracking in JVM. The first chapter of this work describes benchmarking techniques, which will be used for comparison of different allocations trackers. In this work will SPECjvm2008 will be used. It is a benchmark suite for measuring the performance of a Java Runtime Environment (JRE). It contains several real life applications and benchmarks focusing on core java functionality. The SPECjvm2008 workload mimics a variety of common general-purpose application computations. As SPECjvm2008 does not give any information about memory usage a lightweight JVM Tool Interface (JVM TI) agent was created. JVM TI allows a program to inspect the state and to control the execution of other application running in the JVM [1]. The agent works in a separate thread and writes memory usage statistics to a CSV file every second. The agent creates an insignificant overhead, so it does not distort the SPECjvm2008 results. In the next chapters of this work open-source allocations trackers are reviewed. Their work principles, algorithms and memory structures are examined. For measuring allocations tracking efficiency the SPECjvm2008 suite will be run with every tested allocations tracking solution. The obtained data allows comparing memory and performance overhead of different approaches in memory allocations tracking. Chapter 2 introduces HPROF – an example profiler, shipped with the Oracle Java Development Kit (JDK) and uses the JVM TI. In chapter 3 we review the NetBeans profiler, previously known as JFluid. This is full-weight Java profiler integrated with the NetBeans IDE. Chapter 4 is about Eclipse Test and Performance platform. This is a collection of open- source frameworks and services that allows software developers to build test and performance tools. In the last chapter results of using Google’s Allocation Instrumenter are presented. It uses java.lang.instrument package and ASM Java byte code manipulation and analysis framework. For each examined profiler brief description along with implementation details and benchmarking results are given

Optimizing JVM profiling performance for Honest Profiler

Honest Profiler on tööriist, mis võimaldab mõõta Java virtuaalmasina peal jooksvate rakenduste jõudlust. Tööriista poolt kogutud informatsiooni põhjal on võimalik optimeerida vaadeldava rakenduse jõudlust. Käesoleva töö eesmärk on luua lahendusi, mis suurendaksid Honest Profileri tööriista poolt kogutud informatsiooni hulka. Suurem andmete hulk muudab jõudluse mõõtmise tulemused täpsemaks. Töö kirjeldab profiilide kogumise ning Honest Profileri arhitektuuri põhitõdesid. Ühtlasi mõõdetakse Honest Profileri informatsiooni kogumise loogika jõudlust. Töö põhitulem on kolm erinevat lähenemist, mis suurendavad kogutud informatsiooni hulka. Kirjeldatud lahenduste jõudlus ning kogutud informatsiooni hulk verifitseeritakse jõudlustesti abil.Honest Profiler is a profiling tool which extracts performance information from applications running on the Java Virtual Machine. This information helps to locate the performance bottlenecks in the application observed. This thesis aims to provide solutions to increase the amount of useful information extracted by Honest Profiler. Achieving this would increase the accuracy of the performance information collected by Honest Profiler. Thesis will cover the basics of sampling profiling, the architecture of Honest Profiler and measures the performance of Honest Profiler’s data collection logic. As the main result of this thesis, three different solutions for increasing the profiler information output are presented. Their performance and the extracted information amount is evaluated by a benchmark test