Shulou(Shulou.com)06/02 Report--

This article mainly introduces "which is the fastest garbage collector in Java8". In daily operation, I believe many people have doubts about which is the fastest garbage collector in Java8. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "which is the fastest garbage collector in Java8". Next, please follow the editor to study!

OpenJDK 8 has several GC (Garbage Collector) algorithms, such as Parallel GC, CMS, and G1. Which one is the fastest? What if you change the default GC for Java 8 from Parallel GC to G1 (currently recommended) in Java 9? Let's benchmark this.

Benchmark test method

Run the same code six times, each with different VM parameters (- XX:+UseSerialGC,-XX:+UseParallelGC,-XX:+UseConcMarkSweepGC,-XX:ParallelCMSThreads=2,-XX:ParallelCMSThreads=4,-XX:+UseG1GC).

Each run takes about 55 minutes.

Other VM parameters:-Xmx2048M-server

OpenJDK version: 1.8.0R51 (current version of * *)

Software: Linux version 4.0.4-301.fc22.x86_64

Hardware: Intel? Core? I7-4790 CPU @ 3.60GHz

Run 13 OptaPlanner at a time Plan the problem plan. Each run time is 5 minutes. The first 30 seconds are used for JVM preheating, not counting.

Solving the planning problem does not involve IO (except that it takes a few milliseconds to load the input at startup). A single CPU is fully saturated. Many short-lived objects are usually created and then recycled after GC.

The yardstick can be to calculate the score per millisecond, the higher the better. Calculating a proposed planning solution is a problem to be reckoned with: it involves a large number of calculations, including conflict detection between each entity and all other entities.

To run these benchmarks repeatedly locally, you can build from the source code and then run the main class GeneralOptaPlannerBenchmarkApp.

Benchmark test results

Execution result

For ease of viewing, I have compared each GC with the Java 8 default GC (Parallel GC).

The result is clear: the default (Parallel GC) is the fastest.

Raw benchmark data

Relative benchmark data

Should Java 9 be G1 by default?

One proposal is to use G1 as the default GC on the server side of OpenJDK9. My response was to reject the offer:

The average of G1 is 17.60% slower.

G1 is slow for each dataset use case.

Under the * dataset (Machine Reassignment B10), the performance is worse than other datasets, and G1 is 34.07% slower.

If you use a different default GC between the development machine and the server, the credibility of the developer benchmark will be reduced.

On the other hand, there are several details to pay attention to:

The G1 focus is a matter of GC pauses, not throughput. For these use cases (which are computationally heavy), the length of GC pauses has little effect.

This is a (basically) single-threaded benchmark. Benchmark tests that solve multiple problems in parallel or with multithreaded solutions may have different results.

The recommended heap memory for G1 is at least 6GB. The heap memory of this benchmark is 2GB, which requires only so much memory even in the * dataset (Machine Reassignment B10).

Massive computing is just one of the many features of OpenJDK: this is a widely debated issue in the community. If there is proof from other aspects (such as web services), it may be worth changing the default GC. But first, please show me the benchmark for your actual project.

At this point, the study on "which is the fastest garbage collector in Java8" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.