|
A brief history of garbage collection
The Java language may be the most widely used programming language to rely on garbage collection, but it is by no means the first. Garbage collection has been an integral part of many programming languages, including Lisp, Smalltalk, Eiffel, Haskell, ML, Scheme, and Modula-3, and has been in use since the early 1960s.
|
|
Object Creation
I thought that I didn't need to worry about memory allocation. Java is supposed to handle all that for me." This is a common perception, which is both true and false. Java handles low-level memory allocation and deallocation and comes with a garbage collector. Further, it prevents access to these low-level memory-handling routines, making the memory safe. So memory access should not cause corruption of data in other objects or in the running application, which is potentially the most serious problem that can occur with memory access violations
|
|
Java performance programming, Part 1: Smart object-management saves the day
Excessive object creation can be a huge problem in Java programs. Despite continuing improvements in JVM technology for memory management, the object creation and garbage collection cycle is still a very expensive operation.
|
|
Java performance programming, Part 2: The cost of casting
Type-specific code is not just faster than code with type casts; it's also cleaner and safer. Unfortunately, Java sometimes makes it difficult to avoid the use of casting. In this first of two articles focusing on casting, Dennis looks first at the costs of casting (in terms of both program complexity and performance), and then at techniques you can use in your code to reduce the need for casting
|
|
Java performance programming, Part 3: Managing collections
Collections are among the most widely used programming constructs, so poor performance in this area can have repercussions throughout your code. JDK 1.2 provides some major improvements over the very limited collections support included in the original Java libraries, and some current work going on as part of the Java Community Process promises to eventually provide even better options
|
|
Java's garbage-collected heap
A key feature of Java is its garbage-collected heap, which takes care of freeing dynamically allocated memory that is no longer referenced. Because the heap is garbage-collected, Java programmers don't have to explicitly free allocated memory. Here's a hands-on introduction to Java's garbage-collected heap.
|
|
The lean, mean, virtual machine
A key component of Java is the Java Virtual Machine -- a virtual computer, typically implemented in software on top of a "real" hardware platform and operating system, that runs compiled Java programs. Thanks to the JVM, programs written in Java don't have to be rewritten to run on different computers. Here's a hands-on introduction to the JVM
|
|
How the Java virtual machine performs thread synchronization
All Java programs are compiled into class files, which contain bytecodes, the machine language of the Java virtual machine. This article takes a look at how thread synchronization is handled by the Java virtual machine, including the relevant bytecodes.
|
|
Why Garbage Collection?
The Java virtual machine's heap stores all objects created by a running Java application. Objects are created by the new, newarray, anewarray, and multianewarray instructions, but never freed explicitly by the code. Garbage collection is the process of automatically freeing objects that are no longer referenced by the program.
|
|
Why Garbage Collection?
The Java virtual machine's heap stores all objects created by a running Java application. Objects are created by the new, newarray, anewarray, and multianewarray instructions, but never freed explicitly by the code. Garbage collection is the process of automatically freeing objects that are no longer referenced by the program.
|
|
Garbage Collection Algorithms
Any garbage collection algorithm must do two basic things. First, it must detect garbage objects. Second, it must reclaim the heap space used by the garbage objects and make the space available again to the program.
|
|
Reference Counting Collectors
Any garbage collection algorithm must do two basic things. First, it must detect garbage objects. Second, it must reclaim the heap space used by the garbage objects and make the space available again to the program.
|
|
Tracing Collectors
Tracing garbage collectors trace out the graph of object references starting with the root nodes. Objects that are encountered during the trace are marked in some way. Marking is generally done by either setting flags in the objects themselves or by setting flags in a separate bitmap. After the trace is complete, unmarked objects are known to be unreachable and can be garbage collected.
|
|
Compacting Collectors
Garbage collectors of Java virtual machines will likely have a strategy to combat heap fragmentation.
|
|
Copying Collectors
Copying garbage collectors move all live objects to a new area. As the objects are moved to the new area, they are placed side by side, thus eliminating any free space that may have separated them in the old area
|
|
Generational Collectors
One disadvantage of simple stop and copy collectors is that all live objects must be copied at every collection.
|
|
Adaptive Collectors
An adaptive garbage collection algorithm takes advantage of the fact that some garbage collection algorithms work better in some situations, while others work better in other situations. An adaptive algorithm monitors the current situation on the heap and adjusts its garbage collection technique accordingly.
|
|
The Train Algorithm
One of the potential disadvantages of garbage collection compared to the explicit freeing of objects is that garbage collection gives programmers less control over the scheduling of CPU time devoted to reclaiming memory
|
|
Cars, Trains, and a Railway Station
The train algorithm divides the mature object space into fixed-sized blocks of memory, each of which is collected individually during a separate invocation of the algorithm. The name, "train algorithm," comes from the way the algorithm organizes the blocks.
|
|
Collecting Cars
Each time the train algorithm is invoked, it collects either the lowest numbered car of the lowest numbered train or it collects the entire lowest numbered train
|
|
Remembered Sets and Popular Objects
As mentioned previously, the goal of the train algorithm is to provide time-bounded incremental collections of the mature object space of a generational collector
|
|
Finalization
In Java, an object may have a finalizer: a method that the garbage collector must run on the object prior to freeing the object. The potential existence of finalizers complicates the job of any garbage collector in a Java virtual machine.
|
|
The Reachability Lifecycle of Objects
In Java, an object may have a finalizer: a method that the garbage collector must run on the object prior to freeing the object. The potential existence of finalizers complicates the job of any garbage collector in a Java virtual machine.
|
|
The Reachability Lifecycle of Objects
In versions prior to 1.2, every object on the heap is in one of three states from the perspective of the garbage collector: reachable, resurrectable, or unreachable
|
|
Reference Objects
The weaker forms of reachability involve an entity that was first introduced in version 1.2: the reference object. A reference object encapsulates a reference to some other object, called the referent
|
|
Reachability State Changes
As mentioned previously, the purpose of reference objects is to enable you to hold references to objects that the garbage collector is free to collect.
|
|
Caches, Canonicalizing Mappings, and Pre-Mortem Cleanup
The garbage collector treats soft, weak, and phantom objects differently because each is intended to provide a different kind of service to the program. Soft references enable you to create in-memory caches that are sensitive to the overall memory needs of the program
|
|
Heap of Fish:A Simulation
The Heap of Fish applet, shown in Figures 9-2 through 9-5, demonstrates a compacting, mark and sweep, garbage-collected heap. To facilitate compaction, this heap uses indirect handles to objects instead of direct references
|
|
Understanding the IBM Java Garbage Collector, Part 1: Object allocation
This article is the first of three in a series on the IBM Java Garbage Collector (GC), a storage manager for the IBM Java development kits and runtime environments. The series will cover: storage areas used by GC; object allocation; garbage collection; how external interfaces work; and verbosegc and other command line parameters
|
|
Object Initialization in Java
This article describes in detail the process of object initialization in Java programs. It discusses constructors, initializers, instance initialization () methods, initialization and inheritance, object images on the heap, and the order in which an object's variables get initialized. It serves as a companion article to this month's Design Techniques column, "Designing object initialization."
|
|
Designing Object Initialization
This installment of the Design Techniques column begins with a quick look at object-design fundamentals, then goes on to discuss various approaches to designing initializers and constructors so as to facilitate the proper initialization of objects.
|
|
Understanding the IBM Java Garbage Collector, Part 2: Garbage collection
This is the second of three articles in a series on the IBM Java Garbage Collector (GC), which is a storage manager for the IBM Java development kits and runtime environments. Part 1 in this series covered object allocation, and the next article will discuss verbosegc and other command line parameters. In this article Sam Borman reviews how garbage collection works, and describes the three main phases of GC: mark, sweep, and compact. He also discusses concurrent mark and parallel bitwise sweep.
|
|
Understanding the IBM Java Garbage Collector, Part 3: verbosegc and command-line parameters
In this article Sam Borman explains how to interpret verbosegc, and how some of the command-line parameters work. He uses examples to illustrate verbosegc output, and describes the command line parameters that influence GC and when to use them. Information in this article reflects the Java 1.2.2 through 1.3.1 release levels.
|
|
Object Finalization and Cleanup
This installment of the Design Techniques column discusses the design guidelines that pertain to the end of an object's life. I give an overview of the rules of garbage collection, discuss finalizers, and suggest ways to design objects such that finite resources aren't monopolized
|
|
Garbage collection and performance
The past two installments of Java theory and practice have discussed various techniques for garbage collection and the basics of the JDK 1.4.1 garbage collectors. This month, columnist Brian Goetz looks at the performance impact of the choice of collector, how various coding idioms interact with the garbage collector, and how allocation and other related costs have changed in Java virtual machines over the past several years.
|
|
Referencing objects : How you reference objects can seriously affect the garbage collector
Intrepid optimizers Jack Shirazi and Kirk Pepperdine, Director and CTO of JavaPerformanceTuning.com, follow performance discussions all over the Internet, expanding and clarifying the issues they encounter in this column. This month, they set their sights on the Java Games Web site to see how game developers identify and then resolve problems that appear when their application doesn't release objects for garbage collection.
|
|
Handling memory leaks in Java programs
Memory leaks in Java programs? Absolutely. Contrary to popular belief, memory management is still a consideration in Java programming. In this article, you'll learn what causes Java memory leaks and when these leaks should be of concern. You'll also get a quick hands-on lesson for tackling leaks in your own projects.
|
|
Improve your development processes
Performance. It's the one aspect of the Java platform that continually takes abuse. But the overwhelming success of the platform on other fronts makes performance issues worth serious investigation. In this new column, Intrepid optimizers Jack Shirazi and Kirk Pepperdine, Director and CTO of JavaPerformanceTuning.com, follow performance discussions all over the Internet, expanding and clarifying the issues they encounter. This month, they head over to the JavaRanch to cover discussions on compilation speed, exceptions, and heap size tuning.
|
|
Optimize your Java application's performance
Many useful techniques exist for optimizing a Java program. Instead of focusing on one particular technique, this article considers the optimization process as a whole. Authors Erwin Vervaet and Maarten De Cock walk readers through the performance tuning of a puzzle-solving program, applying an assortment of techniques ranging from simple technical tips to more advanced algorithm optimizations. The end result is a spectacular performance increase (more than a million fold) between the first working implementation and the fully optimized solution.
|
|
Improve the performance of your Java code
Many algorithms are expressed most concisely as tail-recursive methods. Compilers can automatically transform such methods into loops and thereby improve program performance, but this transformation is not required by the Java language specification, so not all JVMs will perform it. This means that tail-recursive methods in the Java language can result in unexpectedly large memory usage. In this article, Eric Allen demonstrates that dynamic compilation maintains the language's semantics while static compilation often doesn't.
|
|
Garbage collection on Java 1.1.8 JVMs
In Java applications, the programmer has explicit control of how objects are created but cannot explicitly give back the memory that these objects occupy when they are no longer needed. The process of garbage collection takes care of freeing up space that is no longer used to store objects. This paper gives a short description of garbage collection, why it is needed, and how it works.
|
|
"Heap of trouble" with the wrong heap size
Many Java implementations provide options related to the size and growth of the Java heap. This brief article discusses proper usage of the minimum, ms, and maximum, mx, heap size. Because the minimum parameter is the starting size of the heap, correct (or incorrect) usage of this parameter, as well as the maximum parameter, can significantly impact the performance of your Java application.
|
|
Spotlight on Java performance
IBM's contributions to improvements in Java performance are the result of the combined efforts of research teams around the world. Working in research and development labs in Austin, Haifa, Hawthorne, Hursley, Poughkeepsie, Rochester, Tokyo, and Toronto, these teams are currently tackling new challenges that spring from evolving e-business and Web services technologies. In this interview, IBM Distinguished Engineer Robert Berry addresses the rapidly growing importance of the server environment, the need to integrate the JVM with middleware, and the advent of very large configurations in hardware, and how all of these factors are making new demands on Java performance.
|
|
Garbage collection in the 1.4.1 JVM
Brian Goetz examines how the 1.4.1 JVM actually handles garbage collection, including some of the new garbage collection options for multiprocessor systems.
|
|
Reducing garbage collection frequency
e-BIT bytes editor Iain Lewis offers a helping hand with options that expand or shrink the heap based on how much free space the JVM contains.
|
|
Mash that trash -- Incremental compaction in the IBM JDK Garbage Collector
This article discusses incremental compaction, a new feature in the memory management component of IBM JDK 1.4.0. Incremental compaction is a way of spreading compaction work across different garbage collection cycles, thereby reducing pause times. The authors discuss the need for incremental compaction, the compaction phases at a high level, and some runtime parameters. They also explain how to interpret changes in the verbosegc output.
|
|
Fine-tuning Java garbage collection performance
Is your Java-based application fully using the capabilities of the IBM eServer hardware it's running on? In this article, the author shows how to find out whether garbage collection, the task carried out by Java Virtual Machine in the background to reclaim unusable space, is finely tuned. He then provides several recommendations to address your garbage collection issues.
|
|
Smart object-management saves the day
An object in a program frequently has an internal "state," and the behavior of the object needs to change when its state changes. For example, the acceleration characteristics of a car depend on its current RPM range -- in other words, on its "state." The State pattern takes advantage of polymorphism to implement such state-dependent behavior in an object-oriented program.
|
|
Better object management
Heap exhaustion and excessive garbage collection are often the result of poor object management. Here are a few tips to ensure you're not falling into this trap.
|
|
Guidelines for using the Java 2 reference classes
The Java 2 platform introduced the java.lang.ref package, which contains classes that allow you to refer to objects without pinning them in memory. The classes also provide a limited degree of interaction with the garbage collector. In this article, Peter Haggar examines the functionality and behavior of the SoftReference, WeakReference, and PhantomReference classes and recommends programming idioms for their use.
|
|
The Jikes Research Virtual Machine (RVM)
The Jikes Research Virtual Machine (RVM) is designed to execute Java programs that are typically used in research on fundamental virtual machine design issues. It provides academic and research communities with a flexible testbed to prototype new virtual machine technologies and experiment with a large variety of design alternatives.
|
|
Whose object is it, anyway? : Garbage collection reduces the need to track object ownership -- but it doesn't eliminate it
In a language without garbage collection, such as C++, significant attention must be paid to memory management. For each dynamic object, you must either implement reference counting to simulate the effect of garbage collection, or manage the "ownership" of each object -- identifying which class is responsible for deleting an object. Such ownership is usually not maintained declaratively, but rather by (often undocumented) convention. While garbage collection means that Java developers don't have to worry (much) about memory leaks, sometimes we still do have to worry about object ownership to prevent data races and unwanted side effects. In this article, Brian Goetz identifies some of the situations where Java developers must pay attention to object ownership
|
|
Java Tip 68: Learn how to implement the Command pattern in Java
Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. In procedural languages, this type of communication is accomplished via a callback: a function that is registered somewhere to be called at a later point. Commands are the object-oriented equivalent of callbacks and encapsulate the callback function. This Java Tip demonstrates how to implement the Command pattern in Java.
|
|
To mutate or not to mutate?
Immutable objects have a number of properties that make working with them easier, including relaxed synchronization requirements and the freedom to share and cache object references without concern for data corruption. While immutability may not necessarily make sense for all classes, most programs have at least a few classes that would benefit from being immutable.
|
|
Why finalizers should (and can) be avoided
Finalizers are a necessary evil, but I strongly recommend that they be used only when no other option is available. In this gem, we'll look at the downside of using finalizers and discuss another programming option that can actually strengthen your Java applications.
|
|
Living with the Garbage Collector
The Garbage Collector (GC) is one of the most contentious issues that Java programmers live with. The principle of an independent collector is accepted, but the urge to control it often proves irresistible. Typically, you finish with a resource or resources and look for them to be collected. And they're not. Something must be wrong! IBM provides a means for us to force GC, the System.gc() call, so it must be OK to use it, right? Wrong. Nearly always.
|
|
Prevent your JVM from terminating on user logout
If you run your JVM as an NT service, it will terminate when a user logs out of Windows NT/2000. To solve this problem you need to pass the parameter -Xrs to the JVM.
|
JNI pitfalls
If you run your JVM as an NT service, it will terminate when a user logs out of Windows NT/2000. To solve this problem you need to pass the parameter -Xrs to the JVM.
|
Preventing memory leaks in a Java application with Rational Purify: a case study
Memory management needs to be attended to in Java applications despite the presence of the garbage collector. Learn how one developer used heap data captured in Rational Purify to find and correct the causes of memory leaks in a Java application.
|
Is that your final answer? : Guidelines for the effective use of the final keyword
The final keyword is often misused -- it is overused when declaring classes and methods, and underused when declaring instance fields. This month, Java practitioner Brian Goetz explores some guidelines for the effective use of final.
|
Understand the relationship between mutable Service-Oriented Objects and state machines
In Guideline 1, I said that objects are machines. The kind of machine that service-oriented objects resemble, mathematically speaking at least, is the state machine
|
Java's garbage-collected heap
A key feature of Java is its garbage-collected heap, which takes care of freeing dynamically allocated memory that is no longer referenced. Because the heap is garbage-collected, Java programmers don't have to explicitly free allocated memory. Here's a hands-on introduction to Java's garbage-collected heap.
|
Tuning Garbage Collection
with the 1.3.1 Java Virtual Machine
The Java 2 Platform is increasingly used for large server applications such as web services. These applications demand scalability, and directly benefit from large numbers of threads, processors, sockets and memory. Yet 'big iron' performance has a reputation as an art form, requiring special expertise beyond what is needed for performance on smaller systems. Fortunately, the Java Virtual Machine (JVM)* and Solaris operating environment provide effective implementations of threads, I/O and memory management. This document addresses a common speed bump on the road to scalable high performance: poorly tuned garbage collection (GC).
|
Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine
The JavaTM 2 Platform, Standard Edition (J2SETM platform) is used for a wide variety of applications from small applets on desktops to web services on large servers. In the J2SE platform version 1.4.1 two new garbage collectors were introduced to make a total of four garbage collectors from which to choose. How should that choice be made and what are the consequences of that choice? This document will describe some of the general features shared by all the garbage collectors. It will then discuss tuning options to take the best advantage of those features in the context of the default single-threaded, stop-the-world collector. Finally, it will discuss the specific features of the three other collectors, and discuss the criteria for choosing one of the four collectors.
|
Faster Java garbage collection: IBM JDK 1.4.0
This article discusses incremental compaction, a new feature in the memory management component of IBM JDK 1.4.0. Incremental compaction is a way of spreading compaction work across different garbage collection cycles, thereby reducing pause times. The authors discuss the need for incremental compaction, the compaction phases at a high level, and some runtime parameters. They also explain how to interpret changes in the verbosegc output.
|
Automatic Garbage Collection in Java and C++
The purpose of this writing is to outline my views on automatic garbage collection (AGC) in Java and C++. It is well known that AGC is standard in Java, but is rarely available in C++. Garbage collection concerns objects with dynamic extent (allocated with a new statement in these languages.). Java uses various techniques to automatically discover when these objects are no longer referred to, and to reclaim them. In contrast, C++ programmers manually specify where an object with dynamic extent is to be reclaimed by coding a delete statement.
|
Heap of Fish : A Simulation of a Garbage-Collected Heap
The Heap of Fish applet, included below, demonstrates a compacting, mark and sweep, garbage-collected heap
|
Garbage Collection.
One of the most important features of the Java is garbage collection, also called automatic memory management. In Java while the program is running, the memory is being allocated with new operation. This allocated memory storage is not available until garbage collector sweeps away the unused objects. To make any object unusable make the reference variable pointing to that object as null pointer.
|
Pick up performance with generational garbage collection
With generational garbage collection (introduced in Sun Microsystems's Java HotSpot VM for Solaris), command line parameters control how the JVM uses heap space to perform garbage collection. The default parameters are effective for most small applications that require faster startup and a smaller footprint.
|
J2SE 1.4.1 boosts garbage collection
Java 2 Platform, Standard Edition (J2SE) 1.4.1 introduces three new garbage collection algorithms, effectively doubling the number that existed in J2SE 1.4.0. The new techniques target applications needing high throughput or minimal pause time during execution. This article examines the new algorithms in the broader context of Java garbage collection and provides some hints about when they are appropriate.
|
Weighing in on Java native compilation
When it was first introduced, it seemed that Java native compilation would surely topple the JVM, taking with it the Java platform's hard-fought platform independence. But even with its growing popularity and the increasing number of native compilers on the market, native compilation has a way to go before it poses a real threat to Java code's portability
|
The Reference Objects API allows programs to interact with the garbage collector
This month, Jeff Friesen explores the Reference Objects API, an API that allows your programs to interact with the garbage collector in limited ways. He shows you how to use that API to manage image caches, obtain notification when significant objects are no longer strongly reachable, and perform post-finalization cleanup.
|
The Reference Objects API allows programs to interact with the garbage collector
This month, Jeff Friesen explores the Reference Objects API, an API that allows your programs to interact with the garbage collector in limited ways. He shows you how to use that API to manage image caches, obtain notification when significant objects are no longer strongly reachable, and perform post-finalization cleanup.
|
Not using garbage collection
Java is a garbage-collected run-time system, which frees the programmer from manually tracking allocation and deallocation of memory. However, as in manually managed systems, performance can be improved if you think ahead about the quantity of allocations your program will generate.
|
The basics of Java platform performance
In this introductory lesson, Reggie Hutcherson starts with the basics of Java performance and defines the four main execution workloads in the Java Virtual Machine.
|
Interact with garbage collector to avoid memory leaks
In model-view-controller (MVC) applications, models often accumulate references to unused view objects. These references prevent the view objects from being garbage-collected, even after the user disposes of views that can no longer be used. This tip shows you how to implement your own models to remove unneeded listeners automatically, thus preventing memory leaks. A simple application is included to demonstrate the problem and solution.
|
No Silver Bullet - Garbage Collection for Java in Embedded Systems
The program specifications and hardware constraints of embedded systems result in some unique problems regarding garbage collection. Different garbage collection algorithms are appropriate depending on the embedded systems application, thus preventing garbage collection from being a "silver bullet" problem.
|