Refworkload wls_webapp_atomic JSP_HTTPS_POST_3 throws a lot of exceptions(45,549/s), which seems to be the cause for the slowdown of G1 vs. parallel gc in that benchmark.

According to Scott Oaks, the reason for these exceptions is that this code is checking to see if the client has a certificate or not during SSL setup, and the code that does that throws an exception to indicate that no certificate is present. It turns out that we cannot avoid making that call, so we will have to live with the exceptions. The alternative would be to start the long process to fix the public Java API.

G1 is more expensive generating stack trace since java_lang_Throwable::fill_in_stack_trace(Handle, methodHandle, Thread*) ultimately calls the barrier methods (e.g. java_lang_Throwable::set_backtrace -> throwable->release_obj_field_put -> oop_store() and likely via other paths), which is slower in G1.

Not building the stack trace, i.e. specifying -XX:-StackTraceInThrowable, performance increases more with g1 than with parallel gc, by 1-2%.