Forcing garbage collection

[Dan]

Hello Java Guru's!

Is there a way to force garbage collection in Java?

Before anyone answers I feel I need to state:
- I know about System.gc() and Runtime.gc() and what they do
- I am not suggesting to do this in production code

The purpose of my asking is that I want to test a finializer during a
unit test by allowing something to go out of scope naturally. The
reason why I need it to fall out of scope instead of calling the
finalizer directly is because I am testing that no other references
exist and that the act of letting it fall out of scope makes it
eligible for gc.

So in this specific case, how would I do it? I know that code
profiling tools such as jProfiler can somehow force gc on a remote
JVM. Does anyone know how this works?

In my test cases, the following seems to run it every time... but I
was hoping that there was a more definitive way to do it:

System.gc();
Thread.sleep(1000);

Thank you!

-Dan

PS: I know there is another topic similar to this, but this isn't the
exact same question and I didn't want to hijack the thread.

 

[Eric Sosman]

Hello Java Guru's!

Is there a way to force garbage collection in Java?

Before anyone answers I feel I need to state:
- I know about System.gc() and Runtime.gc() and what they do
- I am not suggesting to do this in production code

The purpose of my asking is that I want to test a finializer during a
unit test by allowing something to go out of scope naturally. The
reason why I need it to fall out of scope instead of calling the
finalizer directly is because I am testing that no other references
exist and that the act of letting it fall out of scope makes it
eligible for gc.

You should not, of course, call finalize() directly.

If I understand correctly, you've got a Thing instance to
which there should be only one reference (or hard reference),
and you want to assert "No other (hard) references exist" by
letting the lone reference go out of scope and then seeing
whether the garbage collector agrees that there are no others.
This latter you hope to do by seeing whether the finalize()
method gets called.

The problem with this approach, it seems to me, is that
it's not clear how long you should wait before concluding that
the Thing has not become garbage. You can call System.gc() --
you can even call it several times, creating megabytes of other
garbage between calls -- but I don't know of any way to be sure
finalize() gets called "promptly." If you *do* observe finalize()
being called, fine -- but if you don't, you won't know whether the
test has failed or whether you needed to wait a little longer and
run GC a few more times.

I suppose you could run some simple experiments to get a feel
for how many GC cycles and how much garbage is needed to be
reasonably sure that finalize() will run. Run the experiments
with all available GC flavors, in client and server settings,
and hope for the best, I guess.

I wonder if you could do something more direct, possibly
using a ReferenceQueue or something else in the java.lang.ref
package. I confess I've used only a few of the things therein,
and only in simple ways, so this isn't so much an Answer as an
Exercise for the Reader ...

Good luck!

 

[Tom Anderson]

Is there a way to force garbage collection in Java?

Before anyone answers I feel I need to state:
- I know about System.gc() and Runtime.gc() and what they do
- I am not suggesting to do this in production code

The purpose of my asking is that I want to test a finializer during a
unit test by allowing something to go out of scope naturally. The
reason why I need it to fall out of scope instead of calling the
finalizer directly is because I am testing that no other references
exist and that the act of letting it fall out of scope makes it
eligible for gc.

First up, rather than using a finalizer, i'd use a PhantomReference:

http://java.sun.com/javase/6/docs/api/java/lang/ref/PhantomReference.html

I don't think much is guaranteed for either approach, but i believe a
PhantomReference is likely to tell you about collection sooner than a
finalizer would. It's definitely a lot classier.

So in this specific case, how would I do it? I know that code profiling
tools such as jProfiler can somehow force gc on a remote JVM. Does
anyone know how this works?

I suspect they do it via JMX - JConsole can do it, and that's a JMX tool.
There's an MBean for the GC:

http://java.sun.com/javase/6/docs/api/java/lang/management/GarbageCollectorMXBean.html

But it doesn't have a method to force collection. There's an extension for
Sun's implementations:

http://java.sun.com/javase/6/docs/j...om/sun/management/GarbageCollectorMXBean.html

But that doesn't have such a method either. But i bet if you dig into this
you'll find a way to do it. Some super sekrit method somewhere.

tom

 

[markspace]

In my test cases, the following seems to run it every time... but I
was hoping that there was a more definitive way to do it:

System.gc();
Thread.sleep(1000);

I don't think there's a way to force the gc to run, but in my experience
it always does run. You can, however, do something more deterministic
by using a phantom reference. Unfortunately, the Thread.sleep() call
seems to be necessary, so I don't know how deterministic this really is.


public class PhantomTest {
public static void main( String[] args )
throws Exception
{
ReferenceQueue<?> refQueue = new ReferenceQueue<Object>();
DiesHorribly die = new DiesHorribly();
PhantomReference<?> ref = new PhantomReference( die, refQueue );
System.out.println( "About to kill " + die );
die = null;
System.gc();
System.out.println( "Done." );
Thread.sleep( 1000 );
System.gc();
System.out.println( "waiting..." );
refQueue.remove();
System.out.println( "The phantom of the OS" );

}

private static class DiesHorribly {

@Override
protected void finalize()
throws Throwable
{
System.out.println( this+" died." );
super.finalize();
}

}
}

 

[John B. Matthews]

I don't think there's a way to force the gc to run, but in my
experience it always does run. You can, however, do something more
deterministic by using a phantom reference. Unfortunately, the
Thread.sleep() call seems to be necessary, so I don't know how
deterministic this really is.

This article proposes calling System.gc() and Thread.yield() in a loop:

<http://www.javaworld.com/javaworld/javaqa/2003-12/01-qa-1212-intern.html>

They also mention "a custom JVMPI (JVM Profiler Interface) agent." I'm
guessing that's the trash can icon in NetBeans' profiler.

[...]

 

[markspace]

i believe a
PhantomReference is likely to tell you about collection sooner than a
finalizer would.

The opposite. Finalizers get run as soon as the object becomes eligible
for GC, on the first GC pass. Then the object is freed up on the second
pass, then "sometime maybe later" the PhantomReference is enqueued.

The difference is that the finalizer is run with the object is still
"live" and in memory. The phantom reference only appears well after the
object is completely gone, and totally GC'd too.

In summary:

finalizer := about to be GC'd
phantom := "He's dead, Jim."

 

[Lew]

The opposite. Finalizers

might

get run as soon as the object becomes eligible
for GC, on the first GC pass

or later.

Then the object is freed up on the second pass,

or later,

then "sometime maybe later" the PhantomReference is enqueued.

The Javadocs for 'finalize()' point out that after that method runs,
"no further action is taken until the Java virtual machine has again
determined that there is no longer any means by which this object can be
accessed by any thread that has not yet died, including possible actions by
other objects or classes which are ready to be finalized, at which point the
object may be discarded."

Since there is no guarantee that other finalizers will run at any given GC
pass, it might take a few passes after a particular object's has run before
the GC *may* (not definitely will) discard it.

 

[Tom Anderson]

or later.


or later,


The Javadocs for 'finalize()' point out that after that method runs,
"no further action is taken until the Java virtual machine has again
determined that there is no longer any means by which this object can be
accessed by any thread that has not yet died, including possible actions by
other objects or classes which are ready to be finalized, at which point the
object may be discarded."

Since there is no guarantee that other finalizers will run at any given GC
pass, it might take a few passes after a particular object's has run before
the GC *may* (not definitely will) discard it.

Maybe using both is the solution. And since objects become weakly
reachable *before* finalization, one of those too!

tom

 

[Dan]

They also mention "a custom JVMPI (JVM Profiler Interface) agent." I'm
guessing that's the trash can icon in NetBeans' profiler.

This is exactly what I was looking for! The JVMPI declares the
following method (http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/
jvmpi.html#RunGC):

void (*RunGC)(void);
"Called by the profiler to force a complete garbage collection. This
function must not be called when GC is disabled."

JVMPI is depreciated in Java 1.5 and is gone in 1.6. It was replaced
with JVMTI which has the following method (http://java.sun.com/javase/
6/docs/platform/jvmti/jvmti.html#ForceGarbageCollection):

jvmtiError ForceGarbageCollection(jvmtiEnv* env)
"Force the VM to perform a garbage collection. The garbage collection
is as complete as possible. This function does not cause finalizers to
be run. This function does not return until the garbage collection is
finished."

This solves the mystery of how Eclipse, Netbeans, and jProfiler can
force a GC; but unfortunately, it can't be used to test my finalizer.

Thanks!

-Dan