Discussion for 8226197: Reducing G1’s CPU cost with simplified write post-barrier and disabling concurrent refinement

[Thomas Schatzl]

Hi all,

  to keep the community in the loop:

On Tue, 2019-06-18 at 18:15 -0700, Man Cao wrote:
> Thanks for both responses!
> I will certainly take a look at JDK-8213108, and will rebase our
> patch on top of JDK-8213108. Hopefully it will make our patch
> smaller.
> 
> Regarding to whether to support G1-throughput mode in the long term,
> could we set up a video conference meeting to chat about it?

We had a meeting yesterday, with the following outcome (a summary of
the notes in the CR; to not keep loose threads hanging here):

- for both Google and Oracle maintaining completely separate barriers
for G1 for "modes" amounts to lots of maintenance overhead (testing,
make sure both modes work, perf regressions, ...) is undesirable.

- the suggested alternative barrier of JDK-8226731 (without the
enqueue) seems to have the same or at least very close performance/cpu
usage according to our (Oracle's) initial measurements which consisted
running these changes through our regular perf benchmark.

I added a patch to the CR based on Man's change that implements this
barrier (that code is not in any way suitable for anything but perf
testing :)).

Man will verify on their workloads and see if it is adequate.

- the recommendation is to implement JDK-8226731 first, which will as
far as we know also benefit throughput/cpu usage of regular G1 in the
same applications, although not to that extent (due to additional write
barrier code and refinement).

- based on that, if the user disables refinement threads on the
commandline as he could now, do not generate the code at the end of the
suggested (post) barrier that enqueues cards. That should result in the
same effect as envisioned in this CR. I do recommend a separate CR from
JDK-8226731; JDK-8226197 could be repurposed for this change :)

This seems to be a very managable cost in maintenance overhead (both
code complexity and testing) while reaping benefits.

- after that, there is some idea to investigate dynamically switching
between the barriers (i.e. enabling/disabling the enqueuing as
required) so that e.g. on startup G1 could skip refinement for maximum
startup throughput, and later enable/disable refinement as required for
minimum pauses.
I think it is best to discuss how to approach this best at a later
date.

I saw that Man already assigned JDK-8226731 to himself to look into
that. Great, thanks! :)

@Man: please feel free to ask questions if there are problems or you
want to discuss changes.

Thanks,
  Thomas