G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]
kirk.pepperdine at gmail.com
Thu Jul 30 06:29:28 UTC 2015
You have to give G1 more memory than what you’d use with the parallel collector. Less memory will lower your throughput.
If you haven’t already, you may want to troll back through the hotspot mailing list to review the interactions that have already taken place on this subject.
On Jul 29, 2015, at 10:04 PM, Andrew Haley <aph at redhat.com> wrote:
> On 07/29/2015 06:55 PM, Doug Lea wrote:
>> On 07/29/2015 12:09 PM, Andrew Haley wrote:
>>> I 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.
>> The problem is that there is a full memory fence when issuing
>> cross-region GC write barriers. Most concurrent producer-consumer
>> designs hit this case frequently, and can run almost arbitrarily
>> slower, down to the rate of issuing fences (MFENCE/DMB/etc).
>> I know that Erik Osterlund (and possibly others) are looking into ways
>> of removing this fence. I sure hope they succeed before jdk9 ships!
> I'm looking at a 5-6% degradation (measured against the parallel GC)
> in performance over a range of benchmarks on the system I measured.
> As I understand it, one of the acceptance criteria of a Java release
> is that it must not have overall worse performance than the previous
> Java release. As it stands, I don't think that this version of Java
> is going to meet that requirement.
More information about the hotspot-dev