3

I understand that GC gets triggered when a new object allocation fails or System.gc() is called. Every GC algorithm suggests that as a first step the GC thread will suspend all the application threads so that they won't affect the GC activity.

But I would like to understand how GC suspends all the running threads? I mean is there any safe points defined by JVM, for example, memory allocation (new object creation) or method invocation, and when application thread reaches these safe points they will be blocked against a GC lock. Is it true? If so, then how about an application thread that does only a simple computation as follows (I know in reality this will never happen), will it ever get suspended?

while(true) {
    a = a + s;
    s = s + a;

    // some computation that doesn't touch any JVM safe points 
}

In these cases, does GC activity carry on without suspending these application threads (and suspend/block later when they try to cross a safe point, for example object allocation)?

But i believe, GC always waits for these application threads to enter the safe points and suspends them before proceeding. Is my assumption true?

Sathish
  • 4,975
  • 3
  • 18
  • 23
  • Just to be clear `System.gc()` does not guarantee GC. It depends on multiple JVM specific parameters. – Aniket Thakur Jun 07 '15 at 06:17
  • Yeah, thats fine.. I'm more interested in how GC suspends the running application threads. – Sathish Jun 07 '15 at 06:18
  • Not all GCs STW. This is implementation specific, so I don't think you'll find points in the vm spec – Vince Jun 07 '15 at 06:24
  • yeah depends on the GC algorithm used. You can read one of my previous [answer](http://stackoverflow.com/questions/21230165/is-concurrent-mark-sweep-cms-a-stop-the-world-event/21230308#21230308). – Aniket Thakur Jun 07 '15 at 06:27
  • Ok, assume that my question is with STW GC. do you know how the application threads are suspended in this case please? – Sathish Jun 07 '15 at 06:32
  • There are several switchable GCs; some of them suspend all thread, some don't – Maurice Perry Jun 07 '15 at 10:07

1 Answers1

7

But I would like to understand how GC suspends all the running threads?

The hotspot implementation uses safepoint polling. To quote:

How safepoints work?

Safepoint protocol in HotSpot JVM is collaborative. Each application thread checks safepoint status and park itself in safe state in safepoint is required. For compiled code, JIT inserts safepoint checks in code at certain points (usually, after return from calls or at back jump of loop). For interpreted code, JVM have two byte code dispatch tables and if safepoint is required, JVM switches tables to enable safepoint check.

Safepoint status check itself is implemented in very cunning way. Normal memory variable check would require expensive memory barriers. Though, safepoint check is implemented as memory reads a barrier. Then safepoint is required, JVM unmaps page with that address provoking page fault on application thread (which is handled by JVM’s handler). This way, HotSpot maintains its JITed code CPU pipeline friendly, yet ensures correct memory semantic (page unmap is forcing memory barrier to processing cores).

more detailed description from the mechanical-sympathy mailing list.

 // some computation that doesn't touch any JVM safe points

The compiler only allows those things if it can prove that they finish in a finite amount of time. Otherwise it inserts safepoint polls

the8472
  • 40,999
  • 5
  • 70
  • 122