RFR: Concurrent code cache evacuation

Roman Kennke rkennke at redhat.com
Wed Jun 28 10:40:45 UTC 2017


Am 28.06.2017 um 12:31 schrieb 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?

Concurrent code cache evacuation is a feature. ShBarriersForConst is a
technical detail (much like +/-ShenandoahReadBarriers, etc).
Concurrent code cache marking is technically separate. I have no problem
putting these two under the same flag if performance and correctness are
both ok. For conc codecache marking we are pretty certain at this point
it is ok, conc codecache evac not so much (yet).

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

This looks ok. I will test it again. Notice that I gave it as much heap
as I could to possibly amplify barriers impact (or rather, reduce GC
threads impact).

Roman


More information about the shenandoah-dev mailing list