RFR: Concurrent code cache evacuation

[Roman Kennke]

Am 28.06.2017 um 12:43 schrieb Aleksey Shipilev:
> On 06/28/2017 12:40 PM, Roman Kennke wrote:
>> 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).
> All right, fine. Let's keep it simple for now, and use only ShBarriersForConst:
>  http://cr.openjdk.java.net/~shade/shenandoah/codecache-conc-evac/webrev.03/
>
> -Aleksey
>
Yep