Have sort question - is it true that all GC in JDK 7 (other than G1) always use stop-the-world for young generation collection?
thanks
For OpenJDK, JRockit, IBM JVM, and Sun/Oracle JDK, the young collection is always stop the world for every available collector.
The only JVM I know of which does not have a stop the world collector is Azul's Zing. (Not free)
While OpenJDK/Hotspot has CMS this is mostly concurrent. There is still stop the world portions and in some cases CMS will fall back to a Full GC which is stop-the-world.
AFAIK, It is hard to find real world examples where G1 is faster in terms of pause time than CMS, however it is improving all the time.
Do your GC logs speak to you
All (almost) Java garbage collectors has some sort of a Stop-the-world phase where all the Java threads (not native threads) are suspended waiting for exclusive system operations to complete. This state is sometimes referred to as a safepoint.
The modern garbage collectors are concurrently running together with the applications threads, which means that the garbage collector perform its work at the same time as the application threads are running. During the garbage collector process there are phases where exclusive access memory is needed, in that phase the application Java threads goes into the safepoint state.
One alternative to get rid of the stop-the-world garbage collections is to go for the Zing JVM with the C4 collector from Azul systems. The implementation has a low pause approach with no stop-the-world collections at all. Instead it is using a concurrent compacting approach with no stop-the-world phase.
No it is not true. Java 7 also supports the older Concurrent Mark Sweep (CMS) collector. CMS is a low pause collector, just like G1.
UPDATE
Apparently CMS is only for the tenured generation ... according to the blog posting that you found at http://blogs.oracle.com/jonthecollector/entry/our_collectors
So that means that your proposition is in fact true.
One could argue that all of the low-pause collectors:
- need to stop the mutator threads to do some phases of their work, and
- may fall back to a Full GC using the mark/sweep collector when they can't keep up.
However, there is a qualitive difference between "mostly concurrent" collectors like G1 and CMS, and other collectors that suspend non-GC threads for the entire duration of the collection process. That is what is normally meant by a "stop the world" strategy.
Related
when configuring the G1GC
we have 2 kinds of thread count
-XX:ParallelGCThreads and -XX:ConcGCThreads
what is the difference, how they are going to impact,
any reference is appreciated.
G1 algorithm has phases which some of them are "stop the world" phases that stops the application during garbage collection, and it also has phases which happens concurrently while application is running(candidate marking etc..), with that information in mind:
ParallelGCThreads option affects the number of threads used for phases when application threads are stopped, and the ConcGCThreads flag affects the number of threads used for concurrent phases.
It is the setting or precisely say JVM tuning settings... we inform JVM to use how many threads in that particular type of Garbage Collection.
I hope you are already aware of what is Garbage Collection, so when JVM runs Garbage Collection, it depends on what algorithm is set for your JVM as default collector.
You might already be knowing that there are various kind of Garbage collectors available, like G1, CMS, etc.
So, based on your setting (here, number of threads) GC algorithm will try to use that many threads for heap cleanup. While JVM runs FULL GC, it halts other threads processing.
Now suppose, your application is live and performing very heavy tasks, multiple users using it for multiple purpose (say very busy app), and JVM running FULL GC now, then in that case, all worker threads will come to a pause and GC will clean up. In this period, if all threads are acquired by JVM, then user will see delay in response. So, you can tell JVM, hey Use only that much (number) thread on that type (CMS or Parallel) of garbage collection run.
To get more on GC types and how they differ, whats suits your needs, refer some good article and docs from oracle.
Here is one reference for the options you mentioned.
-XX:ParallelGCThreads: Sets the number of threads used during parallel phases of the garbage collectors. The default value varies with the platform on which the JVM is running.
-XX:ConcGCThreads: Number of threads concurrent garbage collectors will use. The default value varies with the platform on which the JVM
is running.
Java 10 reduces Full GC pause times by iteratively improving on its existing algorithm.
-XX:ParallelGCThreads
As I understood it G1 does not run its collection cycles concurrently with our application. It will still pause the application periodically and Full GC pauses increase with larger heap sizes.
Then how does it improve performance? Can anyone explain this?
Because it wasn't until Java 10 that G1GC became fully parallel in stop-the-world full GC cycle. As per JEP 307: Parallel Full GC for G1 this improves the latency of the worst case scenario:
The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm. We intend to parallelize the mark-sweep-compact algorithm and use the same number of threads as the Young and Mixed collections do. The number of threads can be controlled by the -XX:ParallelGCThreads option, but this will also affect the number of threads used for Young and Mixed collections.
In fact, Java 11 is recommended if you use G1GC because a lot of works was done on it to reduce its footprint and lower its pauses compared to 10.
A summary was done on the hotspot-gc-use mailing list around the various improvements made on 11, 10 and 9 for G1GC, you can find it at this link:
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2018-June/002759.html
A quick summary from this post on the list :
[...] I would like to point out that overall, with G1, compared to JDK8 it is possible to get 60% lower pause times "for free" on x64
processors (probably more on ARM/PPC due to mentioned specific
changes), at a highly reduced memory footprint.
Two questions about the CMS collector:
Will ParNew run concurrently with a CMS old gen collection.
In the GC log, I do not see the old gen usage after a CMS collection. How can I check how much space is collected in the old gen and how much still remains.
Thanks,
Yes - ParNew will run whilst CMS is performing one of its concurrent phases. This can lead to GC log corruption as the JVM's logging is not thread-safe with respect to the GC threads.
CMS performs a parallel sweep. While this is running, a ParNew can cause objects to be promoted to old gen. The question "how much memory was collected by CMS?" is therefore neither very useful or entirely meaningful.
As I read in the Sun Memory management white paper:
When stop-the-world garbage collection is performed, execution of the application is completely
suspended during the collection
So if a request happens while the garbage collector is running then how is it handled by the application? If the garbage collector takes too long will the application throw an exception? I have not come across such an issue but wanted to know is this possible and what exception gets thrown?
All (almost) Java garbage collectors has some sort of a Stop-the-world phase where all the Java threads are suspended waiting for a exclusive system operations to complete. This state is sometimes referred to as a safepoint.
The modern garbage collectors are concurrently running together with the applications threads, which means that the garbage collector perform its work at the same time as the application. During the garbage collector process there are phases where exclusive access memory is needed, the application threads goes into this safepoint state.
An exception is thrown if the garbage collector cannot recover enough memory to meet the application´s allocation demands.
One alternative to get rid of the stop-the-world garbage collections is to go for the Zing JVM with the C4 collector from Azul systems. The implementation has a low pause approach with no stop-the-world collections at all. Instead it is using a concurrent compacting approach with no stop-the-world phase.
This garbage collector is not in use anymore and replaced by better garbage collectors.
The stop-the-world garbage collector really stopped the complete application (all threads) and cleaned up the heap.
When the garbage collector would take too long (which almost never happens) then an Error would be thrown.
Incomming traffic on network sockets is buffered for the time the collector runs.
Recently I heard Kirk Pepperdine speak about changing garbage collectors for better performance -- but what exactly does that mean and what makes one garbage collector better or different than the other?
You ask two questions:
What does it mean to change garbage collectors in Java for better performance?
This is a huge topic, and like some of the other responders, I urge you to do some reading. I recommend Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning from Sun. The information below mostly comes from there. The "turbo-charging" java article recommended in another answer is older.
In brief, one of the many options we have when running the JVM is to select a garbage collector, of which there are presently three:
The serial collector (selected with the -XX:+UseSerialGC option) - this uses a single thread to do all collection work, and everything waits while it happens.
The parallel collector (selected with the -XX:+UseParallelGC option) - this does minor collections (of the young generation) in parallel, but everything waits during the major collections.
The concurrent collector (selected with the -XX:+UseConcMarkSweepGC option) - this allows most collection operations to happen while the application is running.
What makes one garbage collector better than another?
Your application does. Each of the garbage collectors has a "sweet spot" - a range of application profiles for which it is the superior collector.
First, know that the VM is pretty good at selecting a collector for you, and as with most optimizations, you should not consider second-guessing it until you've identified that your application is not performing well, and that garbage collection is the likely culprit.
In that case, you have to ask these questions: 1) is your app running on a single-processor machine, or multi? 2) Are you more concerned with "minimizing pause time", or with "maximizing throughput"? That is, if you had to choose between the application never pausing but getting less work done overall, versus getting more work done overall, but pausing from time to time, which would you pick?
Roughly speaking, as a starting point:
On a Multi-processor machine, mostly concerned with minimizing pause time, you'd tend to use the Concurrent collector (consider enabling incremental mode)
On a Multi-processor machine, mostly concerned with maximizing throughput, you'd tend to use the Parallel collector (consider enabling parallel compaction)
On a Single-processor machine, with small datasets (up to roughly 100Mb), you'd tend to use the Serial collector
On a Single-processor machine, mostly concerned with maximizing throughput, you'd tend to use the Serial collector
On a Single-processor machine, mostly concerned with minimizing pause time, you'd tend to use the Concurrent collector (consider enabling incremental mode)
Again, though, the VM does a pretty good job of selecting a collector for you, and you're better off not overriding that unless and until you discover that it's not working well enough for your application.
Some collectors are better for throughput, others are better for response time. The difference is usually in how the collector chooses to pause the application. Some such as CMS use mutiple passes to triage the garbage before stopping the application. This triage can happen in a background thread while the application is running, and thus not interfere with your application as much as one that "stops the world" to do a GC.
Edit
Check out this document by sun. Also, about half way down there is a nice image showing the default mark-compact collector against the CMS collector. A picture is worth a thousand words, but the article is a good read too ;) Also worth reading is all the documents on the new G1 collector.
The basic problem is that the way that Java program sees memory (you call "new MyObject" and there it is, and when you are done with it you just forget about it) does not map very well to the underlying operating system and hardware.
The job of the garbage collector is to identify those memory areas which are not in use by an object, and "melt" them together to give a LARGE memory area from where new objects can be allocated. This is very vaguely worded in the Java specification HOW this is done, most likely in order to provide maximum flexibility for the designers of this important task.
Several approaches exist, with advantages and disadvantages. What you usually want is a garbage collector that can keep up in the background with the rate of objects being abandoned, as the only way for it to catch up is to stop the program while catching up. That gives really bad user experiences.
A typical trend for Java objects is that either they live for a very short time (current block or method) or a very long time. Modern garbage collectors deal with this by having multiple pools so that young objects are treated differnetly than old objects.