JVM restriction not for calling GC

Question

How exactly does the JVM determine that it should be a garbage collector? Is there a way to restrict the JVM from invoking the GC?

Answer 1

How exactly does the JVM determine that it should be a garbage collector?

It depends.

• If you use the bandwidth collector, the JVM starts the GC when it cannot allocate a new object in the space (or in one of the spaces) where it should be allocated.

• If you use a low-pause builder, the JVM starts the GC when the free space ratio drops below a custom level.

Is there a way to restrict the JVM from invoking the GC?

Not. If the JVM decides that it needs to start the GC, it will launch it. The only thing you can do is tell the JVM to ignore application code calls to System.gc() .

Answer 2

You cannot tell the JVM not to invoke the GC, but you can tell the JVM to ignore calls to System.gc() via -XX:+DisableExplicitGC .

Answer 3

Typically, the JVM decides to start the garbage collection cycle when one of the heap areas approaches filling. Note that the final decision is dependent on the JVM.

As for telling the JVM not to run the GC for a while, there is no reliable and portable way to do this (other than avoiding heap distribution in general).

If you are trying to minimize GC pauses, Java Performance has some good stuff.

Answer 4

It really depends on the implementation of the virtual machine.

In the other hand:

Explicit garbage collection requests are a symbol that indicates potential performance problems.

Code Correction: a call to System.gc ()

Calling System.gc() , Runtime.getRuntime().gc() and System.runFinalization() not recommended. The code should have the same behavior if garbage collection is disabled using the -Xdisableexplicitgc option or not. In addition, “modern” jvms do a very good job with garbage collection. If non-memory leak memory problems develop in the application, you should use the JVM options, not inside the code itself.

PMD Rule DoNotCallGarbageCollectionExplicitly

Answer 5

Generally speaking, GC only works when necessary. Exception, simultaneous sweep of tokens will start prematurely to avoid stopping the application.

IMHO, The simplest / best solution is not to create so much garbage. You can use a memory profiler to reduce the amount of garbage that you produce. This will reduce the size of your collections and how often they occur. In extreme cases, you can avoid collecting during the day or even a whole week.

The advantage of reducing garbage is that you reduce the cleaning of processor caches from garbage. Your L3 cache is just a few MB, and you are creating a few MB of garbage that will effectively crowd out useful information, slowing down your application.