RFR: Concurrent code cache evacuation

[Aleksey Shipilev]

On 06/28/2017 12:20 PM, Roman Kennke wrote:
> 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.

I was thinking that ShenandoahConcurrentCodeRoots should act as global
killswitch for concurrent code cache ops, both scanning and evacuating. So this
would happen:

 -ShConcCodeRoots ?ShBarriersForConst: scan at STW,       evac at STW
 +ShConcCodeRoots -ShBarriersForConst: scan concurrently, evac at STW
 +ShConcCodeRoots +ShBarriersForConst: scan concurrently, evac concurrently

Maybe what is missing from equation is an option for disabling concurrent scan?

> 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).

Aha. I had just remeasured this by hand:

# -Barriers
Compiler.sunflow  thrpt   10  190.151 ± 1.898  ops/min

# +Barriers
Compiler.sunflow  thrpt   10  188.369 ± 2.842  ops/min


Thanks,
-Aleksey