Feedback on G1GC

Martijn Verburg martijnverburg at
Sun Dec 20 13:04:54 UTC 2015

Hi Fabian,

The best place to take the discussion to will be hotspot-gc-dev - thanks
for following up on this!


On 18 December 2015 at 15:48, Fabian Lange <fabian.lange at>

> Hi,
> since a while I have been recommending and using G1GC for JDK 8
> applications.
> This week I was looking at an application which should be the ideal
> candidate.
> It was given 4GB ram, has a steady memory usage of about 1-2GB and during
> its work it generates only garbage. It reads data from sockets,
> deserializes it, manipulates it, serializes it and writes it out to
> sockets. It is processing 100k to 500k of such requests per second.
> With the default G1 settings the machine was very loaded. The collection
> times were pretty long. It even ran out of memory a few times because the
> GC could not catch up.
> When looking at the logs I was surprised to see extremely small eden/young
> sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1
> was churning on 300MB young.
> I raised the question on
> where Charlie Hunt was so kind to explain the reasons behind the behaviour.
> It either did not make sense to me, or I did not understand the
> explanation.
> What I did is what I always did regardless of the collector: I increased
> young space, knowing it contains mostly garbage.
> The overall behaviour of the JVM was much improved by that.
> I found it irritating, that according to Charlie, the main reason for the
> small eden is the Pause Time Limit. Because GC was not meeting its goal it
> reduced eden. While I observed better results doing the opposite.
> I also enabled -XX:+ParallelRefProcEnabled.
> Logs are available from the above discussion, but I can send them in
> separate mail if desired.
> As far as I can tell the ergonomics are not working for me, and the changes
> I need to do are counter intuitive. From other discussions I learned that
> quite many people observed better overall performance with raising the
> pause time restriction.
> Is there public information to why the current defaults are as they are?
> How would feedback on these defaults work?
> Best regards,
> Fabian

More information about the adoption-discuss mailing list