JVM with no garbage collection

Question

I've read in many threads that it is impossible to turn off garbage collection on Sun's JVM. However, for the purpose of our research project we need this feature. Can anybody recommend a JVM implementation which does not have garbage collection or which allows turning it off? Thank you.

Answer 1

Sun's JVM has no such option. AFAIK, no other JVM has this option either.

You did not state what it is that you are exactly trying to achieve but you have one of two options: either use a profiler and see exactly what the GC is doing, that way you can take its effects into consideration. The other is to compile one of the JVMs from source, and disable GC from there.

Answer 2

Depending on your needs this could perhaps work:

Using the -Xbootclasspath option you may specify your own implementation of API classes. You could then for instance override the implementation of Object, and add to the constructor, a globalList.add(this) to prevent the objects from being garbage collected. It's a hack for sure, but for simple case-study it's perhaps sufficient.

Another option is to take an open source jvm and comment out the parts that initiate garbage collection. I would guess it is not that complicated.

Answer 3

Maybe you could try making your VM's available memory sufficient for GC never to be run.

My (allbeit limited) experience leads me to suggest that the VM is, by default, extremely lazy and extremely reluctant to run GC.

giving -Xmx 16384M (or some such) and making sure that your research subject stays well below that limit, might give you the environment you wish to obtain, allthough even then it will obviously not be guaranteed.

Answer 4

Can you get an openSource JVM and disable it's GC? For example Sun's Hotspot

If there was no Garbage Collection what would you expect to be the semantics of

public myClass {

      public void aMethod() {

            String text = new String("xyz");

      }

}

In the absence of GC any item newed and with a stack scoped reference could never be reclaimed. Even if your own classes could decide not to use local variables like this, or to use only primitive types I don't see how you would safely use any standard Java library.

I'd be interested to hear more about your usage scenario.

Answer 5

I wanted to find a fast way to keep all objects in memory for a simple initial proof of concept.

The simple way to do this is to run the JVM with a heap that is so large that the GC never needs to run. Set the -Xmx and -Xms options to a large value, and turn on GC logging to confirm that the GC doesn't run for the duration of your test.

This will be quicker and more straightforward than modifying the JVM.

Answer 6

If I had this problem I would get IBM's Jikes Research Virtual Machine because

• The run-time system is written in Java itself (with special extensions)
• The whole thing was designed as a research vehicle and is relatively easy to tweak.

You can't turn off GC forever, because Java programs do allocate and eventually you'll run out of memory, but it's quite possible that you can delay GC for the duration of your experiment by telling the JVM not to start collecting until the heap gets really big. (That trick might work on other JVMs as well, but I wouldn't know where to find the knobs to start twirling.)

Answer 7

Take a look at Oracle's JRockit JVM. I've seen very good near-deterministic performance on Intel hardware with this JVM and you can prod and poke the runtime using the Mission Control utility to see how well it's performing.

Though you can't turn GC off completely, I believe that you can use the -Xnoclassgc option to disable the collection of classes. The GC can be tuned to minimize latency at the expense of leaving memory consumption to grow. You may need a license to drop the latency as low as you need if you're going this route.

There is also a Realtime version of the JRockit JVM available but I don't think that there is a free-to-developers version of this available.

Answer 8

You can only turn off the GC if its not actually needed (otherwise your application would run out of memory) and if you didn't need to GC, it shouldn't run anyway.

The simplest option would be to not discard any objects, this will avoid GC being performed (And set the max memory very high so you don't run out).

You may find that you get GCs on startup and you may consider a no-GC when running acceptable.