RFR: Concurrent code cache evacuation

[Roman Kennke]

Hi Aleksey,

I would probably not couple conc codecache evac to
ShenandoahConcurrentCodeRoots, but rather make a new flag (or rename
ShenandoahBarriersForConst once again). The reason for this is that
while concurrent code cache marking is unproblematic with regards to
performance (no new barriers required), concurrent code cache evacuation
is not. It requires more barriers and can thus affect performance. Your
measurements don't show a big regression, but when I was doing my first
experiments with it, the regression with compiler.sunflow was very
pronounced. It is possible that this is gone (with all the changes done
by Roland in the meantime, and probably also with your patch).

Other than that: great stuff!

Roman

Am 28.06.2017 um 12:05 schrieb Aleksey Shipilev:
> Hi,
>
> I would like us to make code cache evacuation concurrent:
>   http://cr.openjdk.java.net/~shade/shenandoah/codecache-conc-evac/webrev.02/
>
> This gives us the benefit of much lower final mark times, where we had to
> evacuate the code cache roots:
>   http://cr.openjdk.java.net/~shade/shenandoah/codecache-conc-evac/perf.txt
>
> Code cache was evacuated at pause because constant oops barriers were stripped
> away as optimization, and this change conflicts with that optimization. So,
> +ShenandoahBarriersForConst is set by default. This may affect correctness, as
> demonstrated by recent Roland's fixes to C2.
>
> Throughput-wise, only Compiler.* tests are regressing ~2% in single-threaded
> mode. The regression is completely gone in fully-threaded configuration. We seen
> no other regressions.
>
> Testing: hotspot_gc_shenandoah, specjvm with +Verify, specjbb with +Verify
>
> Thanks,
> -Aleksey
>