Visualizing Reference Patterns for Solving Memory Leaks in Java

The use of a managed, type-safe languages such as Java in real-time and embedded systems can offer productivity and, in particular, safety and dependability benefits over the dominating unsafe languages at reasonable costs. A JVM that has dynamic memory-management needs to provide an implicit memory-management strategy, that is, for example, a garbage collector (GC) or stack allocation provided by the escape analysis of the JVM's compiler: Explicit management of dynamically allocated memory (i.e., by use of functions such as C's malloc() and free()) is vulnerable to programming errors such as neglected or false memory release operations causing memory leaks or dangling pointers. Such operations have the potential to break the soundness of the type system and are therefore usually not available for strongly typed languages. Type-safe languages in combination with static analyses -- which respect hardware as well as system-specific information -- can efficiently be employed to provide a runtime system including memory management (MM) that is specifically suited to an embedded application on a particular hardware device. In the context of this paper, we present novel memory-management strategy we implemented in our KESO JVM. It is a latency-aware garbage-collection algorithm called LAGC. Also, we introduce the static analyses that can assist LAGC. The application developers have to ensure that there is enough time for the GCs to run. Hardware characteristics such as soft-error proneness of the hardware or the memory layout can also be taken into consideration as demanded by the system configuration. This is achieved by integrating the GCs in the design process of the whole system just as any other user application, which is the reason why this approach is called cooperative memory management. The suggested strategies require reasonably low overhead.

In the previous chapter, we reviewed memory management in Objective-C for a non- ARC environment. But what happens when ARC is enabled? This chapter explores the changes incurred when ARC is employed. Automatic Reference Counting was briefly explained in Chapter 1, but it is really best summarized in Apple’s own words: Automatic Reference Counting (ARC) in Objective-C makes memory management the job of the compiler. By enabling ARC with the new Apple LLVM compiler, you will never need to type retain or release again, dramatically simplifying the development process, while reducing crashes and memory leaks. The compiler has a complete understanding of your objects, and releases each object the instant it is no longer used, so apps run as fast as ever, with predictable, smooth performance.1 KeywordsSource CodeObject TypeOwnership StatusStatic ArrayDynamic ArrayThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Dynamic memory management in real-time systems is difficult because most traditional allocation and deallocation algorithms are unpredictable in terms of their worst-case memory utilization and execution times. This paper describes recent work on a new memory management system designed specifically to support hard-real-time allocation, automatic garbage collection, and defragmentation of the free pool. The memory management system consists of special hardware circuits placed between the CPU's level-two caches and its memory subsystem. Benefits include worst-case allocation delays of two microseconds and typical memory utilizations that exceed binary-buddy allocators by over 30%. A commercial implementation of this technology is currently under development.

Garbage collectors automatically free memory previously allocated by applications. Generally, they discard unreachable objects from memory, leaving reachable objects intact. However, object reachability does not necessarily imply usability, as an object may be obsolete and still reachable. Such objects are usually referred to as loitering objects. Loitering objects introduce a form of memory leak in a Java application. Predicting, tracing and eliminating loitering objects is a difficult problem. In this paper we address this problem. We present a self-healing approach for dealing with loitering objects. Specifically, the paper proposes an algorithm that can be integrated within the Java garbage collector. The algorithm prevents memory leaks resulting from loitering objects by "paging" suspected live objects to disk and reloading them if they are required. As a proof-of-concept, we have implemented and validated the algorithm for the Java Virtual Machine. This could be a first step towards genuine self-healing of memory management problems.

Java is one of the languages that are popular for high abstraction and automatic memory management. As in other object-oriented languages, Java's objects can easily represent a domain model of an application. While it has a positive impact on the design, implementation and maintenance of applications, there are drawbacks as well. One of them is a relatively high memory overhead to manage objects. In this work, we show our experience with searching for this problem in an application that we refactored to use less memory. Although the application was relatively well designed with no memory leaks, it required such a big amount of memory that for large data the application was not usable in reality. We did three relatively simple improvements: we reduced the usage of Java Collections, removed unnecessary object instances, and simplified the domain model, which reduced memory needs up to 88% and made the application better usable and even faster. This work is a case-study reporting results. Moreover, the employed ideas are formulated as a set of antipatterns, which may be used for other applications.

Both managed and native languages use memory safety techniques to ensure program correctness and as a security defense. A critical element of memory safety is to initialize newly allocated memory to zero before making it available to the program. In this thesis I explore the performance impact of zero initialization and show that it comes with a substantial overhead. I also show that this overhead can be largely removed with new designs that exploit both the language semantics of zero initialization and the hardware semantics of memory hierarchies Programmers increasingly choose managed languages to develop large scale applications. One of the reasons is that managed languages offer automatic memory management (garbage collection), which protects against memory leaks and dangling pointers. Garbage collection encourages programs to allocate large numbers of small and medium size objects, leading to significant overheads of zero initializing objects — on average the direct cost of zeroing is 4% to 6% and up to 50% of total application time on a variety of modern processors. Zeroing incurs indirect costs as well, which include memory bandwidth consumption and cache displacement. Existing virtual machines (VMs) either: a) minimize direct costs by zeroing in large blocks, or b) minimize indirect costs by integrating zeroing into the allocation sequence to reduce cache displacement. This thesis first describes and evaluates zero initialization costs and the two existing designs. The microarchitectural analysis of prior designs inspires two better designs that exploit concurrency and non-temporal cache-bypassing store instructions to reduce the direct and indirect costs simultaneously. The best strategy is to adaptively choose between the two new designs based on CPU utilization. This approach improves over widely used hot-path zeroing by 3% on average and up to 15% on the newest Intel i7-2600 processor, without slowing down any of the benchmarks. These results indicate that zero initialization is a surprisingly important source of overhead in existing VMs and that our new software strategies are effective at reducing this overhead. These findings also invite other optimizations, including software elision of zeroing and microarchitectural support.

Real-time embedded software is mostly written in low level language such as C and assembler. But such systems are hard to test, maintain, and port to other platform. The Java language is entering to the real-time embedded systems because of its robustness, simplicity and portability etc. However, It is very difficult to estimate the worst-case execution time of Java code currently. This is due to dynamic class loading and method calls, especially the automatic garbage collection. The paper has research-ed present solutions for garbage collection, and studied the memory management of the real-time specification of Java (RTSJ). Then the rational solute-on for RTSJ is to adapt incremental garbage collection and the region memory management.

Memory management is one of the most boring topics in database research. It plays a minor role in tasks like free-space management or efficient space usage. Here and there we also realize its impact on database performance when worrying about NUMA-aware memory allocation, data compacting, snapshotting, and defragmentation. But, overall, let's face it: the entire topic sounds as exciting as 'garbage collection' or 'debugging a program for memory leaks'. What if there were a technique that would promote memory management from a third class helper thingie to a first class citizen in algorithm and systems design? What if that technique turned the role of memory management in a database system (and any other data processing system) upside-down? What if that technique could be identified as a key for re-designing various core algorithms with the effect of outperforming existing state-of-the-art methods considerably? Then we would write this paper. We introduce RUMA: Rewired User-space Memory Access. It allows for physiological data management, i.e. we allow developers to freely rewire the mappings from virtual to physical memory (in user space) while at the same time exploiting the virtual memory support offered by hardware and operating system. We show that fundamental database building blocks such as array operations, partitioning, sorting, and snapshotting benefit strongly from RUMA.

Ada Gem #79 --- A number of tools and libraries exist to monitor memory usage, detect memory leaks and more generally solve issues with memory management. The Gems in this three-part series offer an overview of these issues and explain how you can benefit from these tools in your own development.

At the beginning of computer science memory management was a big issue with applications requiring to fit in the small amount of available memory (close to a few kilobytes). Hardware evolution has made this resource cheap for the past few years. Available memory is now close to a few hundred gigabytes. But the current evolution in the multi/many-core era tends to make some issues come back. The memory available tends not to follow the increasing number of cores making the memory resource per thread rare again. We also encounter new issues with the requirement to manage a bigger space with many more allocated objects. This new aspect increases the probability of memory leaks. It also increases the probability of memory management performance issues. Hence, with MALT we provide a tool to track the memory allocated by an application. We then map the extracted metrics onto the source code, just like kcachegrind does with valgrind for the CPU performance. Compared to most available tools, MALT can also be used to track potential performance losses due to bad allocation patterns (too many allocations, small allocations, recycling large allocations, short-lived allocations...) thanks to the various metrics it exposes to the user. This paper will detail the metrics extracted by MALT and how we present them to the user thanks to a nice web based graphical interface which is missing with most of the available Linux tools.

Go is a concurrent, garbage-collected, statically typed programming language that was developed at Google in 2009. Because of its straightforward, effective, and low learning curve, it is a well-liked option for developing online applications, command-line tools, and scalable network services. Garbage collection, which takes care of memory management automatically for you, is another key component of Go. As a result, there is no longer a requirement for manual memory management, which lowers the possibility of memory leaks and other issues. But it does come with a cost, as the Garbage collector takes CPU and Memory. In this paper, we will run some performance analysis with different GOGC options.

Many programming languages have a system of garbage collection to automate memory management. Problems such as unexpected memory leak still may occur due to the automation of memory management. Weak reference has been proposed as a solution to such problems. However, the use of weak reference often requires consideration of memory release timing, which is difficult for developers. In this study, we investigate the use of weak reference on open source projects. More concretely, we investigated the domain of software projects where the weak reference was used, the timing of the introduction of the weak reference, the usage method, the presence or absence of the test code for weak reference, and the case of failure to introduce weak reference in the Java language. The survey showed that weak references were used in 73 repositories, about one-third of the total 202 repositories, and that weak references were most common in test code.

Parallel workstation clusters and MPI for sparse systems in computational science

Java runtime frees applications from manual memory management by its automatic garbage collection (GC), at the cost of stop-the-world pauses. State-of-the-art collectors leverage multiple generations, which will inevitably suffer from a full GC phase scanning the whole heap and induce a pause tens of times longer than normal collections, which largely affects both throughput and latency of the entire system. In this paper, we analyze the full GC performance of HotSpot Parallel Scavenge garbage collector comprehensively and study its algorithm design in depth. We find out that heavy dependencies among heap regions cause poor thread utilization. Furthermore, many heap regions contain mostly live objects (referred to as dense regions), which are unnecessary to collect. To solve these problems, we introduce two kinds of optimizations: allocating shadow regions dynamically as compaction destination to eliminate region dependencies and skipping dense regions to reduce GC workload. Evaluation results show the optimizations lead to averagely 2.6X (up to 4.5X) improvement in full GC throughput and thereby boost the application performance by 18.2% on average (58.4% at best).

While automatic garbage collection has relieved programmers from manual memory management in Java-like languages, managing resources remains a considerable burden and a source of performance problems. In this paper, we present a novel technique for automatic resource management based on static approximation of resource lifetimes. Our source-to-source transformation tool, CLOSER, automatically transforms program code to guarantee that resources are properly disposed and handles arbitrary resource usage patterns. CLOSER generates code for directly disposing any resource whose lifetime can be statically determined; when this is not possible, CLOSER inserts conditional disposal code based on interest-reference counts that identify when the resource can be safely disposed. The programmer is only required to identify which types should be treated as resources, and what method to invoke to dispose each such resource. We successfully applied CLOSER on a moderate-sized graphics application that requires complex reasoning for resource management.