From http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-July/019482.html

"I [Andrew Haley] am concerned that G1 does not perform well with some important workloads.  In particular, on heavily-loaded systems some multi-threaded programs which generate a lot of garbage run
significantly more slowly with G1.  I've been measuring the performance loss and it's about 20-30%, depending on the application.

I don't think that this is a particularly unusual case for Java, and surely an important measure of a garbage collector is how well it works when heavily loaded in this way.

I've not been using an artificial benchmark because I don't think that it would be usefully representative.  Instead, I've written a small test case which uses the Java compiler API to compile real-world Java
code over many threads.

A typical run, of 15 seconds with 12 threads, looks like this:

 $ hs-comp/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 15 12
12 threads, 15 seconds
Warmup
Run
Time: 15.73s, 10.68 compiles/s
 $ hs-comp/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 15 12
12 threads, 15 seconds
Warmup
Run
Time: 15.87s, 8.38 compiles/s

So, here G1 is 27% slower than the Parallel GC.  IMO it would make perfect sense to use the Parallel GC instead of G1 for this application.

I have uploaded my test case to http://people.redhat.com/~aph/CompilerSpeed.tar It's a netbeans
project.  If you'd like to try it, download it, untar it, and do this:

java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 15 12

The first number is the time in seconds to run the test for, the
second is the number of threads to use.  I normally set the number of
threads to the number of hardware threads on the machine."

Investigate the reasons for the difference, and see if there is something that can be fixed.