Is Concurrent Mark Sweep (CMS) a stop the world event?

Question

I see many unloading of classes and my entire system will hang during that period of time..

[Unloading class sun.reflect.GeneratedMethodAccessor117]
[Unloading class sun.reflect.GeneratedConstructorAccessor1896]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor485]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor579]
.... // about 1700 of them

at the same time I do not see a spike in perm space, so it doesn't seems to be a GC event.

I wish to know the following

IS Concurrent Mark Sweep collection a stop the world event?

Does it happen even when the perm space is not full?

Velarize

See this JDK bug report, it may be relevant. The very printing of those messages may be a cause of your hangs (even without the mentioned closing of stdout). Are you using an older version of the Java runtime? – Rawboned

Answer 1

CMS is a type of GC and is divided into phases

As you can see two phases - Initial mark and Remark are stop the world events.

Source : Under Reviewing Generational GC and CMS section.

Does it happen even when the perm space is not full?

AFAIK for this you should have CMSClassUnloadingEnabled with UseConcMarkSweepGC. And FGC will be triggered when permgen area reaches it's threshold.

Also though Concurrent Sweep(phrase (4)) is not STW event if permgen area get filled up(and GC is still processing permgen area) it may led to stopping all process threads and only GC thread running till all required memory is reclaimed.

Hodeida

can I assume Unloading class sun.reflect -> is in phrase (4)? – Velarize

This literal copypasta doesn't help answer OP's specific question. – Rawboned

Answer 2

CMS is not an "event". It is a garbage collector. CMS does have a couple of phases where everything is stopped, but under normal circumstances these are very short (a few milliseconds). In general, if you get a long pause it means that the CMS is not able to keep up with the rate of garbage generation (within the constraints that have been set), and that the JVM has had to perform a full GC using the "mark-sweep" collector ... which is stop the world.

Depending on your JVM, it may be that the permgen only gets collected when a full GC occurs, and that classes are only collected / unloaded when the permgen is GC'ed.

But you can't infer that the class unloading causes the long pauses. In fact, it is more likely the other way around if your GC stats say that the permgen is not filling up.

It is also possible that your logging of class unloading is causing the "stop the world" problem: see http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6637203

---

Observations:

• If you have thousands of messages about unloading dynamically created classes, then I would take a look at the architecture of your system. Are you over-using proxy classes?

• With Java 8, permgen goes away and is replaced with metaspace. Upgrading may ease your problems.

Saar

Answer 3

Usually perm gc doesn't make hang up issue.

The reason is, Perm is usually stabilized after all classes in application has been loaded. it can be a result of hang up. It means, if JVM doesn't have enough memory. It tries to Full-GC. As a part of the full gc, Perm will be GCed.

About the question u asked CMS also makes Full GC. It just reduce # of Full GC. During Minor GC, it also collect Old memory area.

In my opinion, you may have a problem in Heap memory and it makes a # of Full GC and make a hang issue. So u need to check memory usage by using Visual JVM tools or some kinds of GC log analysis. You may find that the Old memory area are full and JVM tried to GC it. but sufficient memory is not freed and it retry gc . and retry retry..etc.

I think you may have a memory leak. issue. So it is better to GC log analysis and if it is memory leak issue, u need to have heap dump and analysis it.

Lament

"Perm is usually stabilized after all classes...has been loaded" may be true for some applications, but clearly not OP's, which shows the unloading of ephemeral classes which were generated at runtime by an optimization in the Reflection API called inflation. This is not at all unusual, most applications dynamically generate bytecode for one purpose or another. – Rawboned