Major Garbage collection with Concurrent Mark Sweep Collector?

Question

I have gone thru this Link and got some questions on Major Garbage collection and Parallel collector

Question1:-

Link says "Often a major collection is much slower because it involves all live objects" , i did not get how working on live objects make major collection slower in comparison Minor collection which works on mix of unreachable objects and live objects.

Question2:-

Link says "Major garbage collection are also Stop the World events" .

On other hand it says "CMS collector attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads" So does CMS collector stop the main application thread till it completes or it runs concurrently with application thread

Question3:-

As there objects is moved from eden >(Minor GC) surivivor >(Minor GC) old generation > (Major GC) > Clean up old generation and compact it.

As per my understanding object memory location is changed when object is either moved from surivivor to old generation or when compaction is done major GC( though object memory location is not changed when its moved fron eden to survivor space)

Answer 1

For Concurrent Mark Sweep:

1. The key word here is all . “A major collection is much slower because it involves all live objects.” Not just a few at a time, but all of them.

2. CMS normally runs concurrently with the application, but when the heap is too full, or has too much fragmentation, the entire program is paused for a full garbage collection of all garbage. This is really slow, because all the garbage is collected, but also runs even more slowly than you'd expect because the major collection is single-threaded . No matter how many cores your machine has, only one thread on one of them will do any work for Java during the major collection.

3. CMS does not normally move objects around, except during a major collection. CMS can run concurrently because all it's doing is freeing up dead objects. But this can result in a lot of fragmentation, and if there isn't a 'hole' in the heap big enough for a large new object that's being created, CMS will stop-the-world and do a major collection. Part of that is compacting the entire heap, and moving all the objects in the heap to one end of it, making the largest 'hole' possible at the other end of the heap for new allocations.