State of G1's "throughput barriers"?
manc at google.com
Fri Nov 15 02:02:11 UTC 2019
Great to hear more interests on this!
Yes, I'm still working on it. The most challenging part is JDK-8226731,
which requires implementing a new synchronization mechanism between Java
threads and GC refinement threads. There are some unresolved issues, and I
a separate CR for this synchronization mechanism soon.
As for the throughput barrier itself (JDK-8226197 or JDK-8230187), it is
simpler to implement. I have implemented a prototype for JDK11 and deployed
some production services internally. However, from a code health and
perspective, it is much cleaner to push it after JDK-8226731 is resolved.
On Tue, Nov 12, 2019 at 1:42 AM Thomas Schatzl <thomas.schatzl at oracle.com>
> Hi Clemens,
> On 09.11.19 15:54, Clemens Eisserer wrote:
> > Hi,
> > With great excitement I read about the proposal to add a
> > throughput-mode to G1 - has there been any progress on this?
> > In some cases the throughput overhead G1 introduced compared to CMS is
> > quite noticeable, especially for the case where 2-5s pauses are quite
> > tolerable - i really hoped to get an option to trade a bit of latency
> > for better throughput.
> > Thanks, Clemens
> the throughput barrier effort (or actually: optimize G1 when
> disabling refinement) afaict consists of two main steps:
> - changing the existing barrier so that the throughput barrier is not
> completely different, allowing some interesting further optimizations.
> This is mostly JDK-8087198 (currently out for review), and JDK-8226731,
> which improves the existing barrier already a bit.
> - enabling the smaller barrier if concurrent refinement is disabled (via
> a new -XX:-G1UseConcRefinement). This is JDK-8134303 and ultimately
> Man Cao from Google is working on this, and it seems that we'll get at
> least the first big part soon. :)
> Maybe Man wants to chime in for further details.
More information about the hotspot-gc-dev