Skip to main content

disable garbage collection

6 replies [Last post]
Joined: 2006-06-20
Points: 0


I'd like to disable the garbage collector so during testing I can determine how much heap size has been used for various operations in our web-app.

thanks in advance for any ideas,


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-02-15
Points: 0

For a rough measurement without adding code, try different NewSize settings -XX:NewSize=???
and monitor garbage collection.
I've used this to get much faster operation of fairly short lived but memory intensive invocations of java.

Joined: 2006-01-17
Points: 0

Is it possible to resize the heap programmatically?
eg. while is such a scope, resize.
while out of scope, return to default size...etc.

If this is possible, gc effect may be disabled for performance critical I correct?

- Jer A.

Joined: 2005-07-11
Points: 0

No, you can't resize the heap programmatically. The heap size is set at
startup time, with the -Xms and -Xmx command line options. The heap must
be in contiguous virtual address space, so the address space must be reserved
early in the lifetime of the process. The best you can hope for here is to set
-Xms to something smaller than -Xmx to allow for times when you need more
memory. But even this has potential issues (heap shrinkage happens only
on full gc boundaries, so you won't free that memory up for potentially a very
long time).

GC really cannot be disabled, and you don't want it disabled either. If you
could disable it, what would happen if your space prediction was wrong?
One the heap fills up, if the GC is disabled you are essentially dead.
Attempting to control the timing of GC events with calls to System.gc() is
also error prone, particularly in multi threaded applications. Furthermore,
System.gc() typically results i a full collection, which can be very expensive
on large heaps.

Depending on what you are really trying to accomplish, something like
ByteBuffer.allocateDirect() or might help you out here.
These both result in non-heap memory getting allocated. However, there
are reference objects associated with the underlying native resources and
they too may take some time to collect. Furthermore, allocating direct and
mapped byte buffer objects is far more expensive than allocating a plain
old java object on the Java heap. So, you don't want to be allocating these
often - these types of objects are one of the rare cases where object pooling
makes sense.

If you really need to control GC timing, you probably want to consider looking
at the Java RTS system and making use of ImmortalMemory and Non-Heap
Realtime Threads.


Joined: 2005-07-11
Points: 0

You can't disable the garbage collector. The best you can do is to increase the size of the heap (which also means sizing a very large young gen) to prevent the need for a garbage collection.

One technique for doing what you want to do is to call System.gc() before your measurement and again after it and see what the difference is. However, that will show how much is live after you've finished the measurement interval. With -verbosegc -XX:+PrintGCDetails data, you'd probably be able to figure out how much was allocated by looking at the before and after sizes.

Another technique might be to use the NetBeans profiler:

Joined: 2003-06-10
Points: 0

Side note: Upto version 1.4, you were able to disable the garbage collector using the start option -noasyncgc.

Using System.gc() doesn't force the garbage collection to take place. It's nothing but a suggestion to the VM, that it might be a good time to perform gc.

The only way to get more details, is to use any kind of profiler.

Joined: 2005-07-11
Points: 0

Looking back at previous releases, the last time -noasyncgc did anything is in 1.1. In 1.2 and later the argument is still accepted (for backward compatibility), but it is ignored.

For the HotSpot JVM, System.gc() does a full GC immediately, however you are correct the spec indicates that it's just a hint. The HotSpot implementation could be changed at any time, so relying upon that is a mistake. However, for this particular exercise, it would have the desired effect.