[pt] Inúmeras linguagens de programação oferecem suporte a finalizadores e referências fracas. Não obstante, de maneira geral esses mecanismos são relativamente pouco conhecidos e pouco usados por programadores. Mesmo entre pesquisadores e desenvolvedores de linguagens não existe muito consenso quanto à sua semântica, que varia consideravelmente entre diferentes implementações. Neste trabalho buscamos explorar os conceitos de finalizadores e de referências fracas, suprindo a ausência de uma especificação clara e abrangente, e permitindo uma melhor compreensão, implementação e uso dos mecanismos correspondentes. Como ponto de partida realizamos um amplo levantamento sobre como é feito o suporte a finalizadores e referências fracas em diferentes linguagens de programação, identificando as características comuns, os problemas, e as questões semânticas mais relevantes associadas às implementações consideradas. Para garantir uma maior precisão em nossa análise, utilizamos um modelo abstrato de uma linguagem de programação com gerenciamento automático de memória. Através deste modelo especificamos formalmente a semântica de finalizadores e referências fracas, incluindo descrições das suas principais variantes e mecanismos relacionados. Além disso, provamos certas propriedades inerentes a linguagens de programação com gerenciamento automático de memória, indicando como estas são afetadas pela introdução de finalizadores e referências fracas. Por fim, consideramos possíveis estratégias de implementação desses mecanismos em diferentes tipos de sistemas. Algumas das opções semânticas investigadas impõe um custo de processamento expressivo, o que frequentemente inviabiliza a sua adoção na prática. / [en] Most mainstream programming languages support finalizers and weak references. In spite of that, these abstractions are still modestly known by programmers in general. Even among language designers there seems to be no common view on how to define their semantics, and language implementations certainly reflect that. In this thesis we explore the concepts of finalizer and weak reference by discussing several important issues that, as far as we know, have not been explored by other authors. After presenting a survey on how finalizers and weak references are supported by actual programming languages, we thoroughly examine their semantics and discuss alternative implementation strategies. We also use an operational approach to develop a formal model for reasoning about garbage collection and its interaction with client programs. By explicitly representing low-level details, such as heap memory and its addresses, we were able to clearly specify memory management actions, and prove several important memory-related language invariants. Using this model we describe a formal semantics for finalizers and weak references, exploring some of its many subtleties. We believe that the topics covered here can serve as a relevant reference for further investigations, and also help to guide actual implementations.

This study evaluates the performance of Kotlin and Java on Android Runtime using four benchmarks from the Computer Language Benchmarks Game suite, for which a total of 12 benchmark implementations are studied. The metrics used to evaluate the performance includes runtime, memory consumption, garbage collection, boxing of primitives as well as bytecode n-grams. To benchmark the languages, a benchmark application has been developed intended to run on an Android phone. The results indicate that Kotlin is slower than Java for all studied benchmarks by a varying factor. Furthermore, the use of idiomatic Kotlin features and constructs results in additional heap pressure and the need of boxed primitives. Other interesting results indicate the existence of an underlying garbage collection overhead when reclaiming Kotlin objects compared to Java. Furthermore, Kotlin produces larger and more varied bytecode than Java for a majority of the benchmarks. / Denna studie utvärderar prestandan mellan Kotlin och Java på Android Runtime genom 12 implementationer av fyra benchmarks från The Computer Language Benchmarks Game. De mätvärden som använts för att utvärdera prestandan inkluderar körtid, minnesanvändning, garbage collection, boxing av primitiver samt bytekod n-grams. För att benchmarka språken har en benchmarkapplikation tagits fram för Android. Resultaten visar att Kotlin är långsammare än Java för samtliga benchmarks. Vidare resulterar användandet av idiomatiska Kotlin-funktioner i ökad minnesanvänding samt behovet att representera primitiver som klasser. Andra intressanta resultat inkluderar existensen av en overhead för garbage collectorn för frigörandet av objekt som allokerats av Kotlin jämfört med Java. Vidare producerar Kotlin större bytekodfiler och uppvisar mer varierad bytekod än Java för en majoritet av de benchmarks som studerats.

Today's mobile development resides in the two main operating systems Android and iOS. It is popular to develop mobile applications individually for each respective platform, referred to as native development. To reduce additional costs, cross-platform solutions have emerged that enable shared development for both platforms. Kotlin Multiplatform Mobile (KMM) is a relatively unexplored cross-platform tool developed by JetBrains. The purpose of this study is to evaluate the performance of iOS applications developed in KMM compared to native Swift. We compare the two approaches for developing iOS apps by compiling a benchmark suite and measuring the performance metrics execution time, memory consumption, and CPU usage. Our benchmark suite is a collection of 7 benchmarks consisting of high-level functionalities networking and database management, as well as low-level computational tasks from the Computer Language Benchmarks Game (CLBG) suite. For the studied benchmarks, the results indicate that KMM generally achieves faster execution times, as higher memory consumption and CPU usage. but with a trade-off overhead in higher memory consumption and CPU usage. We have found KMM to achieve up to 2,7 seconds faster execution time, consume up to 390MB more memory, and up to 30% more CPU than with native Swift. libraries achieve faster execution times, but with a trade-off overhead in increased memory consumption and CPU usage. Besides, our results highlight correlations between the garbage collection cycles of KMM with profiling patterns of memory consumption and CPU usage. the specific benchmark implementations analyzed, and the device used to benchmark them. studies are therefore needed to further generalize our conclusions. / Den nutida mobilutvecklingen domineras av de två huvudsakliga operativsystemen Android och iOS. Det är populärt att utveckla mobilapplikationer separat för varje plattform, så kallad native utveckling. För att minska kostnader relaterade till native utveckling har plattformsoberoende lösningar tillkommit, som istället möjliggör delad utveckling för båda plattformarna. Kotlin Multiplatform Mobile (KMM) är ett relativt outforskat plattformsoberoende verktyg utvecklat av JetBrains. Syftet med denna studie är att utvärdera prestandan hos iOS-applikationer utvecklade i KMM jämfört med native Swift. Vi jämför de två tillvägagångssätten för att utveckla iOS-appar genom att sammanställa en benchmark-svit och mäta prestandametrikerna exekveringstid, minnesanvändning och CPU-användning. Vår benchmark svit består av 7 benchmark-program som omfattar högnivåfunktionaliteter som nätverk- och databashantering, samt lågnivåfunktionaliteter med benchmark-algoritmer från Computer Language Benchmarks Game (CLBG)-sviten. För att exekvera benchmark-programmen och samla in prestandametriker har en applikation utvecklats och använts för att utföra våra experiment på en iOS-enhet. För de undersökta benchmark-programmen visar resultaten att KMM generellt uppnår snabbare exekveringstider, men med en kompromiss i form av ökad minnesanvändning och CPU-användning. Vi har observerat att KMM kan uppnå upp till 2,7 sekunder snabbare exekveringstid, förbruka upp till 390MB mer minne och upp till 30% mer CPU-användning jämfört med native Swift. Dessutom antyder våra resultat korrelationer mellan KMM Garbage Collection cykler och profileringsbeteendet i dess minnes- och CPU-användning.

Despite the built-in garbage collector, Java programs can still suffer the memory leak problem resulted from the unhealthy programming style of retaining unwanted references. This paper presents an aspect-based tool for assisting programmers in locating such references to fix the problem. This tool, FindLeaks, utilizes an aspect to collect memory consumption statistics and object references created during a program’s execution and analyzes them for detecting memory leaks. The distinctive feature of FindLeaks is that it reports not only suspected classes of leaked objects but also where in the source the unwanted references were created. Besides, this paper also reports our experience with FindLeaks on three open source Java programs and how we enhanced it to lower its overhead.

Made available in DSpace on 2014-12-17T14:55:13Z (GMT). No. of bitstreams: 1 GleydsonAFL.pdf: 2185056 bytes, checksum: 094b58b4341884e4f12979b1aa1e99e0 (MD5) Previous issue date: 2007-02-02 / The lava Platform is increasing1y being adopted in the development of distributed sys?tems with higb user demando This kind of application is more complex because it needs beyond attending the functional requirements, to fulfil1 the pre-established performance parameters. This work makes a study on the Java Vutual Machine (JVM), approaching its intemal aspects and exploring the garbage collection strategies existing in the literature and used by the NM. It also presents a set of tools that helps in the job of optimizing applications and others that help in the monitoring of applications in the production envi?ronment. Doe to the great amount of technologies that aim to solve problems which are common to the application layer, it becomes difficult to choose the one with best time response and less memory usage. This work presents a brief introduction to each one of tbe possible technologies and realize comparative tests through a statistical analysis of the response time and garbage collection activity random variables. The obtained results supply engineers and managers with a subside to decide which technologies to use in large applications through the knowledge of how they behave in their environments and the amount of resources that they consume. The relation between the productivity of the technology and its performance is also considered ao important factor in this choice / A plataforma Java vem sendo crescentemente adotada no desenvolvimento de siste?mas distribu?dos de alta demanda de usu?rios. Este tipo de aplica??o ? mais complexa pois necessita al?m de atender os requisitos funcionais cumprir os par?metros de desem?penho pr?-estabelecidos. Este trabalho realiza um estudo da m?quina virtual lava (NM) abordando seus aspectos internos e explorando as pol?ticas de coleta de lixo existentes na literatura e as usadas pela JVM. Apresenta tamb?m um conjunto de ferramentas que auxiliam Da tarefa de otimizar aplica??es e outras que auxiliam no monitoramento das aplica??es em produ??o. Diante da grande quantidade de tecnologias que se apresentam para solucionar pro?blemas inerentes ?s camadas das aplica??es, toma-se dif?cil realizar escolha daquela que possui o melhor tempo de resposta e o menor uso de mem?ria. O trabalho apresenta um breve referencial te?rico de cada uma das poss?veis tecnologias e realiza testes compara?tivos atrav?s de uma an?lise estat?stica da vari?vel aleat?ria do tempo de resposta e das atividades de coleta de lixo. Os resultados obtidos fornecem um subs?dio para engenheiros e gerentes decidirem quais tecnologias utilizarem em aplica??es de grande porte atrav?s do conhecimento de como elas se comportam nestes ambientes e a quantidade de recursos que consomem. A rela??o entre produtividade da tecnologia e seu desempenho tamb?m ? considerada como um fator importante nesta escolha

New PCI-e flash cards and SSDs supporting over 100,000 IOPs are now available, with several usecases in the design of a high performance storage system. By using an array of flash chips, arranged in multiple banks, large capacities are achieved. Such multi-banked architecture allow parallel read, write and erase operations. In a raw PCI-e flash card, such parallelism is directly available to the software layer. In addition, the devices have restrictions such as, pages within a block can only be written sequentially. The devices also have larger minimum write sizes (>4KB). Current flash translation layers (FTLs) in Linux are not well suited for such devices due to the high device speeds, architectural restrictions as well as other factors such as high lock contention. We present a FTL for Linux that takes into account the hardware restrictions, that also exploits the parallelism to achieve high speeds. We also consider leveraging the parallelism for garbage collection by scheduling the garbage collection activities on idle banks. We propose and evaluate an adaptive method to vary the amount of garbage collection according to the current I/O load on the device. For large scale distributed storage systems, flash memories are an excellent choice because flash memories consume less power, take lesser floor space for a target throughput and provide faster access to data. In a traditional distributed filesystem, even distribution is required to ensure load-balancing, balanced space utilisation and failure tolerance. In the presence of flash memories, in addition, we should also ensure that the numbers of writes to these different flash storage nodes are evenly distributed, to ensure even wear of flash storage nodes, so that unpredictable failures of storage nodes are avoided. This requires that we distribute updates and do garbage collection, across the flash storage nodes. We have motivated the distributed wearlevelling problem considering the replica placement algorithm for HDFS. Viewing the wearlevelling across flash storage nodes as a distributed co-ordination problem, we present an alternate design, to reduce the message communication cost across participating nodes. We demonstrate the effectiveness of our design through simulation.