Welcome!

Java IoT Authors: Liz McMillan, Yeshim Deniz, Pat Romanski, Elizabeth White, Zakia Bouachraoui

Related Topics: Java IoT, IBM Cloud, Containers Expo Blog

Java IoT: Article

Anatomy of a Java Finalizer

Experimenting on finalizer implementations in various Java Virtual Machines

A couple of patterns that could cause Java heap exhaustion were identified from years of research at IBM. One interesting scenario was observed when Java applications generated an excessive amount of finalizable objects whose classes had non-trivial Java finalizers.

What Is a Java Finalizer?
A Java finalizer performs finalization tasks for an object. It's the opposite of a Java constructor, which creates and initializes an instance of a Java class. A Java finalizer can be used to perform postmortem cleanup tasks on an instance of a class or to release system resources such as file descriptors or network socket connections when an object is no longer needed and those resources have to be released for other objects. You don't need any argument or any return value for a finalizer. Unfortunately the current Java language specification does not define any finalizers for a Java class or interface when a class or interface is unloaded. Let's take a closer look at finalize() method of java.lang.Object that provides an instance method, finalize() for finalization:

protected void finalize() throws Throwable

When a Java object is no longer needed, the space occupied by the object is supposed to be recycled automatically by the Java garbage collector. This is one of the significant differences in Java and is not found in most structural programming languages like C. If an instance of a class implements the finalize() method, its space cannot be recycled by the garbage collector in a timely fashion. Worst case, it may not be recycled at all.

Any instances of classes that implement the finalize() method are often called finalizable objects. They will not be immediately reclaimed by the Java garbage collector when they are no longer referenced. Instead, the Java garbage collector appends the objects to a special queue for the finalization process. Usually it's performed by a special thread called a "Reference Handler" on some Java Virtual Machines. During this finalization process, the "Finalizer" thread will execute each finalize() method of the objects. Only after successful completion of the finalize() method will an object be handed over for Java garbage collection to get its space reclaimed by "future" garbage collection. I did not say "current," which means at least two garbage collection cycles are required to reclaim the finalizable object. Sounds like it has some overhead? You got it. We need several shots to get the space recycled.

Finalizer threads are not given maximum priorities on systems. If a "Finalizer" thread cannot keep up with the rate at which higher priority threads cause finalizable objects to be queued, the finalizer queue will keep growing and cause the Java heap to fill up. Eventually the Java heap will get exhausted and a java.lang.OutOfMemoryError will be thrown.

A Java Virtual Machine will never invoke the finalize() method more than once for any object. If there's any exception thrown by the finalize() method, the finalization of the object is halted.

You are free to do virtually anything in the finalize() method of your class. When you do that, please do not expect the memory space occupied by each and every object to be reclaimed by the Java garbage collector when the object is no longer referenced or no longer needed. Why? It is not guaranteed that the finalize() method will complete the execution in timely manner. Worst case, it may not be even invoked even when there are no more references to the object. That means it's not guaranteed that any objects that have a finalize() method are garbage collected. That's a potential hazard from a memory management perspective and, needless to say, there is considerable overhead for queuing, dequeuing, running the finalize() method, and rescanning the object in the next garbage collection cycle.

If you want to run cleanup tasks on objects, consider finalizers as a last resort and implement your own cleanup method, which will be more predictable. It's very risky to rely on finalizers for postmortem cleanup tasks, especially if your finalizable objects have references to native resources.

Hands-on Experience with Java Finalizer
We can easily simulate this scenario with a couple of test applications and take a look at dumps and traces to see what's happening inside of the Java heap and threads for hands-on experience.

Let's build a couple of Java classes to recreate typical scenarios.

In ObjectWYieldFinalizer, we can implement the method finalize() with Thread.yield() so that finalize() cannot complete its execution (see Listing 1) (Listings 1-7 can be downloaded here.)

The Thread.yield() method prevents the currently executing thread from running and allows other threads to execute. If the Finalizer thread calls this finalize() method, it will pause its execution.

In ObjectWExceptionFinalizer, the finalizer() method immediately throws a java.lang.IndexOutOfBoundsException. If the Finalizer thread calls this finalize() method, the object finalization won't be completed because of the exception and there's no second chance to run the finalize() method (see Listing 2).

In ObjectWEmptyFinalizer, we don't implement any code in the finalize() method (see Listing 3). ObjectWOFinalizer doesn't have any finalize() method (see Listing 4).

Let's run each of the classes to see what happens. Sun's Java Virtual Machine (JVM) can be used with the following options for the class TestObjectWYieldFinalizer.

/sun1.6.0_10/bin/java -Xmx50m -verbosegc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError TestObjectWYieldFinalizer > verbosegc.txt

It looks very complicated. Why do we need those command-line options? Well, without those options, we only get a little information about Java garbage collection activities like this:

[Full GC 50815K->45644K(50816K), 0.2276940 secs]
[Full GC 48780K->46415K(50816K), 0.2233279 secs]
[Full GC 49551K->49551K(50816K), 0.2396315 secs]
[Full GC 50815K->50815K(50816K), 0.1886312 secs]
[Full GC 50815K->49219K(50816K), 0.1964926 secs]
[Full GC 50815K->50815K(50816K), 0.1865343 secs]
[Full GC 50815K->50815K(50816K), 0.1836961 secs]

We only get a type of garbage collection (Full GC), total Java heap usage before garbage collection (50,815K), total Java heap usage after garbage collection (45,644K), a high watermark of total Java heap (50,816K), and time spent in the garbage collection (0.2276940 secs).

High watermark is the size of the current Java heap. The Java heap can expand its size up to a maximum size or contract to manage Java heap effectively.

The -XX:+PrintGCDetails option lets the JVM provide information on each generation in the Java heap.

We can see Java heap usage and the time (in seconds) spent in Java garbage collection of each new generation, tenured generation, and permanent generation with the -XX:+PrintGCDetails option in the following example:

[GC [DefNew: 3520K->3520K(3520K), 0.0001143 secs][Tenured: 43897K->47295K(47296K), 0.2110999 secs] 47417K->47415K(50816K), [Perm : 17K->17K(12288K)], 0.2115593 secs]
[Times: user=0.22 sys=0.00, real=0.22 secs]

In tenured generation, Java heap usage was 43,897KB before this Java garbage collection. Java heap usage reached 47,295KB after Java garbage collection; 47296K is the size of the high watermark of the tenured generation; 0.2110999 second was spent to collect the tenured generation. Unfortunately we do not see the maximum size of each generation with the -XX:+PrintGCDetails option alone.

With -XX:+PrintGCTimeStamps, we can get a timestamp for each garbage collection like this:

1.393: [GC 1002K->106K(5056K), 0.0001036 secs]

This garbage collection started 1.393 seconds after the JVM started.

The -XX:+PrintHeapAtGC option provides extensive information about each Java garbage collection (see Listing 5).

We can even see the address range of each generation. Unfortunately there's no timestamp for each garbage collection with -XX:+PrintHeapAtGC option alone.

The last option, -XX:-HeapDumpOnOutOfMemoryError allows the JVM to dump the Java heap to a file when an allocation from the Java heap cannot be satisfied or a java.lang.OutOfMemoryError is thrown. This option was introduced in Sun Java 1.4.2 update 12 and Sun Java 5.0 update 7.

If you want to experiment with IBM's Java Virtual Machine, all you need is a -verbosegc command-line option. You do not need any of these: -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC, or -XX:+HeapDumpOnOutOfMemoryError.

Let's take a look at what happened to the class while we talked about Sun JVM's command-line option. We've got java.lang.OutOfMemoryError from TestObjectWYieldFinalizer:

Exception in the thread "main" java.lang.OutOfMemoryError: Java heap space
at java.lang.ref.Finalizer.register(Finalizer.java:72)
at java.lang.Object.<init>(Object.java:20)
at ObjectWYieldFinalizer.<init>(ObjectWYieldFinalizer.java:2)
at TestObjectWYieldFinalizer.main(TestObjectWYieldFinalizer.java:11)

"java.lang.OutOfMemoryError: Java heap space." That means we got Java heap space exhaustion. The JVM could not allocate any more Java heap while running the method java.lang.ref.Finalizer.register(), which is on line 72 of Finalizer.java. Finalizer.java? Of course, we did not write Finalizer.java. That's a part of the JVM. We can also check verbosegc.txt to which we redirected the garbage collection trace (see Listing 6).

About 3.711 seconds after the JVM started, we got java.lang.OutOfMemoryError. The Java heap dump is written to pid124.hprof.

Analysis of Java Garbage Collection Traces
We can use a tool to analyze this trace. The IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) is one of top five technologies at alphaWorks. I have implemented patented algorithms to predict future failures related to Java heap exhaustion in this tool. Please refer to United States Patent No. 7,475,214 if you are interested in the algorithms. Although we don't need these algorithms to investigate simple problem like this, you might be able to find situations where you could get some insight from fortune tellers. We can get a copy of the tool here.

PMAT parses verbose garbage collection (GC) trace, analyzes Java heap usage, and recommends possible solutions based on pattern modeling of Java heap usage.

The following features are included:

  • GC analysis
  • GC table view
  • Allocation failure summary
  • GC usage summary
  • GC duration summary
  • GC graph view
  • GC pattern analysis
  • Zoom in/out/selection/center of chart view

The tool can also parse Sun's Java garbage collector traces, including the following:

  • Serial collector
  • Throughput/parallel collector
  • Concurrent collector
  • Incremental/train collector

We can start version 3.2 of the tool with a jar file in the download package. (V3.2 was the latest version when this article was written.)

# /usr/java5/bin/java -Xmx200m -jar ga32.jar

The tool provides a headless mode but let's bring up the graphical user interface mode for easy demonstration. We can click on the "N" icon to open Sun's trace file. We can click on "I" for IBM's trace file as seen in Figure 1.

We can see in Figure 2 the analysis result and recommendation virtually instantly.

More Stories By Jinwoo Hwang

Jinwoo Hwang is a software engineer, inventor, author, and technical leader at IBM WebSphere Application Server Technical Support in Research Triangle Park, North Carolina. He joined IBM in 1995 and worked with IBM Global Learning Services, IBM Consulting Services, and software development teams prior to his current position at IBM. He is an IBM Certified Solution Developer and IBM Certified WebSphere Application Server System Administrator as well as a SUN Certified Programmer for the Java platform. He is the architect and creator of the following technologies:

Mr. Hwang is the author of the book C Programming for Novices (ISBN:9788985553643, Yonam Press, 1995) as well as the following webcasts and articles:

Mr. Hwang is the author of the following IBM technical articles:

  • VisualAge Performance Guide,1999
  • CORBA distributed object applet/servlet programming for IBM WebSphere Application Server and VisualAge for Java v2.0E ,1999
  • Java CORBA programming for VisualAge for Java ,1998
  • MVS/CICS application programming for VisualAge Generator ,1998
  • Oracle Native/ODBC application programming for VisualAge Generator ,1998
  • MVS/CICS application Web connection programming for VisualAge Generator ,1998
  • Java applet programming for VisualAge WebRunner ,1998
  • VisualAge for Java/WebRunner Server Works Java Servlet Programming Guide ,1998
  • RMI Java Applet programming for VisualAge for Java ,1998
  • Multimedia Database Java Applet Programming Guide ,1997
  • CICS ECI Java Applet programming guide for VisualAge Generator 3.0 ,1997
  • CICS ECI DB2 Application programming guide for VigualGen, 1997
  • VisualGen CICS ECI programming guide, 1997
  • VisualGen CICS DPL programming guide, 1997

Mr. Hwang holds the following patents in the U.S. / other countries:


Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
vishetty 07/30/09 07:28:00 AM EDT

Hi,
you seem to say that,
"If there's any exception thrown by the finalize() method, the finalization of the object is halted.", But the Java Language specification seems to say "If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates".
Is this is a IBM JVM specific behavior?

IoT & Smart Cities Stories
The Founder of NostaLab and a member of the Google Health Advisory Board, John is a unique combination of strategic thinker, marketer and entrepreneur. His career was built on the "science of advertising" combining strategy, creativity and marketing for industry-leading results. Combined with his ability to communicate complicated scientific concepts in a way that consumers and scientists alike can appreciate, John is a sought-after speaker for conferences on the forefront of healthcare science,...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
DXWorldEXPO LLC announced today that Ed Featherston has been named the "Tech Chair" of "FinTechEXPO - New York Blockchain Event" of CloudEXPO's 10-Year Anniversary Event which will take place on November 12-13, 2018 in New York City. CloudEXPO | DXWorldEXPO New York will present keynotes, general sessions, and more than 20 blockchain sessions by leading FinTech experts.
Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how to bring data stored in a cloud database to the edge of the network (and back again) whenever an Internet connection is available. In his session at 17th Cloud Expo, Ben Perlmutter, a Sales Engineer with IBM Cloudant, demonstrated techniques for replicating cloud databases with devices in order to build offline-first mobile or Internet of Things (IoT) apps that can provide a better, faster user e...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of ...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Rodrigo Coutinho is part of OutSystems' founders' team and currently the Head of Product Design. He provides a cross-functional role where he supports Product Management in defining the positioning and direction of the Agile Platform, while at the same time promoting model-based development and new techniques to deliver applications in the cloud.
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...