JEP 307 Parallel Full GC for G1 Improves
G1 worst-case latencies by making the full GC parallel. 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 old implementation of the full GC for G1 used a single
threaded mark-sweep-compact algorithm. With JEP 307 the full GC has been
parallelized and now use the same amount of parallel worker threads as
the young and mixed collections.

The
JVM has been modified to be aware that it is running in a Docker
container and will extract container specific configuration information
instead of querying the operating system. The information being
extracted is the number of CPUs and total memory that have been
allocated to the container. The total number of CPUs available to the
Java process is calculated from any specified cpu sets, cpu shares or
cpu quotas. This support is only available on Linux-based platforms.
This new support is enabled by default and can be disabled in the
command line with the JVM option:

-XX:-UseContainerSupport

In addition, this change adds a JVM option that provides the ability to specify the number of CPUs that the JVM will use:

-XX:ActiveProcessorCount=count

This count overrides any other automatic CPU detection logic in the JVM.

JDK-8186248Allow more flexibility in selecting Heap % of available RAM

Three
new JVM options have been added to allow Docker container users to gain
more fine grained control over the amount of system memory that will be
used for the Java Heap: