State of G1's "throughput barriers"?

[Man Cao]

Hi Clemens,

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
mutator
threads and GC refinement threads. There are some unresolved issues, and I
will draft
a separate CR for this synchronization mechanism soon.

As for the throughput barrier itself (JDK-8226197 or JDK-8230187), it is
actually
simpler to implement. I have implemented a prototype for JDK11 and deployed
for
some production services internally. However, from a code health and
maintenance
perspective, it is much cleaner to push it after JDK-8226731 is resolved.

-Man


On Tue, Nov 12, 2019 at 1:42 AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> 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
> JDK-8226197).
>
> 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.
>
> Thanks,
>    Thomas
>