JVM with no garbage collection

I've read in many threads that it is impossible to turn off garbage collection on Sun's JVM. However, for the pur开发者_StackOverflow中文版pose 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.

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.

^{(In hindsight, this may not work. I vaguely recall seeing evidence that implied that the JVM does not always respect the -Xms setting, especially if it was really big. Still, this approach is worth trying before trying some much more difficult approach ... like modifying the JVM.)}

^{Also, this whole thing strikes me as unnecessary (even counter-productive) for what you are actually trying to achieve. The GC won't throw away objects unless they are garbage. And if they are garbage, you won't be able to use them. And the performance of a system with GC disabled / negated is not going to indicative of how a real application will perform.}

UPDATE - From Java 11 onwards, you have the much simpler option of using the Epsilon (no-op) garbage collector; see

• JEP 318: Epsilon: A No-Op Garbage Collector (Experimental)

You add the following options when you launch the JVM:

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

When the heap is filled, no attempt is made to collect garbage. Instead, the Epsilon GC terminates the JVM.

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.

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.

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.

the question is old but for those who might be interested, there is a proposal to

Develop a GC that only handles memory allocation, but does not implement any actual memory reclamation mechanism. Once available Java heap is exhausted, perform the orderly JVM shutdown.

JEP draft: Epsilon GC: The Arbitrarily Low Overhead Garbage (Non-)Collector

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.

There actually exists a dirty hack to temporarily pause GC. First create a dummy array in Java. Then, in JNI, use GetPrimitiveArrayCritical function to get hold of the pointer to the array. The Sun JVM will disable GC to ensure that the array is never moved and the pointer stays valid. To re-enable GC, you can call the ReleasePrimitiveArrayCritical function on the pointer. But this is very implementation specific since other VM impl may pin the object instead of disabling GC entirely. (Tested to work on Oracle Jdk 7 & 8)

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.

Can you get an open source JVM and disable its GC, for example Sun's Hotspot?

If there was no Garbage Collection what would you expect to be the semantics of code like this?

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.

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.)